下面从顾客进店点餐开始。方括号中的编号对应一个独立模块。
[01 顾客进店] ──► [02 点餐 / User Prompt] ──► [03 Agent / 主厨接单]
“宫保鸡丁，不要花生；我对花生过敏” │
▼
[04 观察当前状态]
▲
[05 Context / 当前操作台] ─────────────────────────────────────┤
点菜单 · 食材 · 灶台状态 · 工具返回结果 │
│
[06 Memory / 顾客与任务记忆] ──────────────────────────────────┤
过敏史 · 口味偏好 · 桌号 · 已完成工序 │
▼
[07 Skill / 菜谱与出餐规范] ──────────────────────────► [08 规划做法]
配方 · 顺序 · 火候 · 摆盘 · 过敏原处理
┌────────── Agent Harness / 执行与反馈循环 ──────────┐
│ │
[04 观察] ──► [08 规划] ──► [09 动手制作] ──► [10 检查结果] ──► [11 完成？] │
▲ │ │
└───────────────────────── 否：调整后继续 ──────────────┘ │
│ 是 │
└─────────────────────────────────────────┼───────────┘
▼
[12 装盘出餐]
[09 动手制作] ──┬─► [13 本地 Tool / 刀具、炒锅、烤箱]
│
└─► [14 MCP / 标准连接协议] ──┬─► [15 Tool / 外部设备与工位]
└─► [16 Resource / 库存与食材信息]
│
工具与资源的返回结果 ───────────────────────────────────────────┴─► [05 Context]
[17 RAG / 检索流程] ──► 检索 [16 Resource / 菜谱与安全规范] ──► [05 Context]
[18 Guardrail / 食品安全红线] ───────────► 约束 [08 规划做法]
过敏原必须拦截 · 生熟分开 · 温度达标
[19 Sandbox / 厨房权限隔离] ─────────────► 限制 [09 动手制作]
限制可使用的设备、区域和数据
[20 Tracing / 后厨工单记录] ◄──────────── [10 检查结果]
记录判断、工具调用、执行结果和返工原因
[21 Evals / 厨师考核] ───────────────────► 测试 [03 Agent + Harness]
用盲测、过敏原案例、出餐速度和成本考核
[12 装盘出餐] ──► [22 Human in the loop / 店长或传菜员终检]
├─► 合格 ──► [23 上菜给顾客]
└─► 不合格 ──► 返回 [04 观察当前状态]
缺货、换菜或过敏原不确定 ──► [24 向顾客确认] ──► 更新 [02 点餐]
核心概念
“官方定义”并非来自同一个标准组织。下面优先采用 OpenAI 官方文档；MCP、Tool 和 Resource 采用 MCP 官方规范。其余没有唯一标准的术语，使用主流工程定义并明确说明。
| 概念 | 餐厅类比 | 在点餐案例中的作用 | 技术定义（正式表述） |
|---|---|---|---|
| Model | 厨师的大脑 | 理解订单、判断做法和处理异常 | 接收输入并生成输出的机器学习模型。在 Agent 系统中，模型通常负责推理、决策以及生成工具调用请求；它本身不等于完整的 Agent。 |
| Agent | 从接单到出餐的主厨 | 主动观察、规划、制作、检查并返工 | 以模型为核心、代表用户完成目标的系统。它能够管理任务执行过程，基于当前状态决定下一步，并通过工具采取行动，直到完成、失败或转交人工。 |
| Agent Loop | 反复查看订单、制作和试味 | 让主厨在菜品不合格时调整并继续制作 | Harness 在用户、模型与工具之间反复协调的执行循环，典型过程为：准备上下文 → 调用模型 → 执行工具 → 返回结果 → 判断是否继续。OpenAI：Codex agent loop |
| Skill | 菜谱与出餐规范 | 告诉主厨配方、工序、火候和摆盘标准 | 面向可重复工作流的可复用能力包，通常由 SKILL.md 加可选的脚本、参考资料和资源组成；系统先加载元数据，选中后再读取完整内容，实现渐进式披露。OpenAI Codex：Skills |
| Tool | 刀、锅、烤箱 | 执行切配、翻炒和烘烤等具体动作 | 具有明确名称、说明和输入结构的可调用操作，使模型能够查询数据、调用 API、修改文件或执行计算；模型请求调用，宿主程序负责真正执行。MCP：Tools |
| MCP | 厨房统一调度接口 | 让主厨用一致方式调用不同设备和工位 | Model Context Protocol：连接 AI 应用与外部系统的开放标准，采用 Host–Client–Server 架构，服务器可暴露 Tools、Resources 和 Prompts。MCP 官方简介 |
| Resource | 冰箱和食材仓库 | 为主厨提供食材、库存等可读取信息 | MCP 中向 AI 应用提供上下文信息的数据源，可来自文件、API 或数据库；通常由应用读取并决定如何放入模型上下文。MCP：Resources |
| Harness | 整套餐厅运营系统 | 管理订单、循环、设备、权限、返工和交付 | 围绕 Agent Loop 的运行与编排基础设施，负责上下文组装、工具执行、状态持久化、内存、权限、沙箱、重试和终止条件等。该词是工程概念，不是单一协议标准。OpenAI：Agents SDK Harness |
| Context | 当前操作台 | 放着这次订单、食材状态和工位返回结果 | 某次模型调用实际可见的信息集合，例如系统指令、用户输入、对话历史、检索内容、Skill 指令和工具返回值。它受上下文窗口容量限制。 |
| Memory | 顾客档案与工单记忆 | 记住过敏史、口味、桌号和制作进度 | 在当前步骤之外保存并在需要时恢复的信息，用来把先前工作中的有用上下文带到后续步骤或会话。实现可以是线程状态、摘要、文件或数据库记录。 |
| RAG | 临时查菜谱库 | 按需检索具体做法和食品安全要求 | Retrieval-Augmented Generation：生成前从外部知识源检索相关内容，并将检索结果加入模型输入，使回答基于可更新、可追溯的外部信息。它是一种架构模式，不是独立 Agent。 |
| Guardrail | 食品安全红线 | 阻止过敏原污染和其他危险操作 | 对 Agent 的输入、输出或工具调用执行的验证与约束，用于检测或阻止不安全、越权、不合规或不满足业务规则的行为。Guardrail 可以由规则、代码或模型实现。 |
| Sandbox | 厨房权限隔离 | 限制不同角色能接触的设备与操作 | 受控的隔离执行环境，通过操作系统或运行平台限制 Agent 能访问的文件、网络、命令和资源；它控制“技术上能做什么”，而审批策略控制“何时必须先问人”。OpenAI Codex：Sandbox 与审批 |
| Tracing | 后厨工单记录 | 记录接单、用料、工序、检查和返工过程 | 对一次 Agent 运行中的模型调用、工具调用、交接、Guardrail 和其他事件进行结构化记录，用于调试、监控、性能分析和审计。 |
| Evals | 厨师考试与抽检 | 测试味道、安全、速度和异常处理能力 | 使用明确的数据集、任务、评分标准和指标，对模型或 Agent 的正确性、可靠性、安全性、成本与延迟进行可重复测量。Evals 是测试方法，不是运行时模块。 |
| Human in the loop | 店长、传菜员或顾客确认 | 在换菜、过敏原和最终出餐等关键节点把关 | 在自动执行流程中保留人工监督、判断或授权节点；当操作高风险、不可逆、信息不足或需要责任确认时，Agent 暂停并请求人类决定。 |
最小记忆版本
Model = 厨师的大脑
Agent = 从接单一直做到出餐的主厨
Skill = 菜谱和出餐规范
Tool = 刀、锅、烤箱等厨房工具
MCP = 主厨连接设备和工位的统一接口
Harness = 包含订单、厨房、权限、反馈和质检的整套餐厅系统
Agent 的核心工作循环：
看订单和厨房状态 → 规划做法 → 动手制作 → 检查味道 → 不合格则调整