素材
篇一：概念篇：Agent：什么是智能体（篇一：概念篇）
篇二：案例篇：拆解我们正在使用的 ChatGPT 桌面客户端。
篇一先讲概念，篇二再用我每天深度使用的 ChatGPT 做案例，与这些概念一一对应。
下面拆解我们正在使用的 ChatGPT
就从 ChatGPT 改写这篇文章 Agent：什么是智能体（篇二：案例篇）开始：
普通回答停在“建议怎么写”。 Agent 要让文件真的发生变化，并证明改对了。
先看全貌：四个部分怎样配合
篇一把 Agent 压成四个部分。放进这次任务：
| 核心部分 | 在 ChatGPT 中负责什么 |
|---|---|
| Model，大脑 | 理解目标，决定下一步 |
| Context，工作台 | 放入本轮需要的目标、规则、文件和工具结果 |
| Tools，手脚 | 读取文件、运行命令、搜索网页、修改环境 |
| Runtime / Harness，运行系统 | 组装 Context、执行工具、保存状态、处理权限和验收 |
还可以从三层诊断问题：
| 层次 | 核心问题 | 这次任务里的例子 |
|---|---|---|
| Prompt | 任务怎么说 | 是补充旧文，还是重写为案例篇 |
| Context | 这一轮给模型看什么 | 当前文章、项目规则、官方资料、报错 |
| Harness | 整个系统怎样跑 | 搜索文件、执行补丁、回填错误、检查结果 |
Prompt 是 Context 的一部分。Harness 每一轮组装 Context，再把模型的决定变成行动。
第一层：一句话进入系统，会变成一张工作单
界面上只有一个输入框，模型收到的却不只是用户消息：
- 当前目标和验收条件。
- 项目目录和相关文件。
Thread中仍然有效的历史。AGENTS.md和命中的 Skill。- 可用工具与权限。
- 最近的工具结果和报错。
Context 不是整个仓库和全部历史。它是这一轮最相关的工作材料。
- 太少，模型会猜
- 太多，重点会被淹没
第二层：模型做决定，Runtime 做执行
模型主要产生两类结果：
- 生成内容。
- 生成工具调用意图。
例如，模型可以提出：
工具：exec_command
参数：搜索编号 313 的笔记这只是一张申请单。Runtime 还要检查工具、参数和权限，执行后再把成功结果或错误放回 Context。
模型负责决定下一步。Runtime 负责让下一步真实发生。
这只是根据官方产品行为与通用 Agent 架构做的工程抽象
第三层：AGENTS.md 管长期规则，Skill 管具体工序
模型会写 Markdown，却不知道这个项目的规矩。例如，下面的都是我的一些要求：
os/notes是长期笔记真源。- 教程结尾必须有“考考你”和“参考”。
- 修改文件要保留用户已有改动。
- 用户没要求时，不能提交或推送。
这些规则来自两处：
| 机制 | 大白话 | 这次任务里的作用 |
|---|---|---|
AGENTS.md | 项目合同 | 规定长期边界、权限和协作方式 |
| Skill | 专项工序卡 | 规定这类教程怎样读取、改写和验收 |
官方文档说明，处理项目时会从项目根目录走到当前工作目录，沿途读取 AGENTS.md；越靠近当前目录的规则越具体。
Skill 的价值，是把反复验证过的做法按需放进任务，不让用户每次重写一大段 Prompt。
第四层：失败结果会推动下一轮决定
这次任务真的失败过
ChatGPT 最初按旧文件名读取篇二，终端返回：
No such file or directory因为我改名文章标题名称，改为 “
xxx，篇二：案例篇”
它没有继续猜路径，而是用 rg --files 搜索稳定编号 313，找到当前文件后继续。
错误在这里不是终点，而是新的 Observation：
行动结果进入 Context，模型据此重新决定下一步。
这就是最小 Agent Loop。Agent 的关键能力不是永远不犯错，而是看见真实结果后会不会转弯。
第五层：Tools 让 ChatGPT 接触真实环境
| 工具 | 大白话 | 适合做什么 |
|---|---|---|
| 文件与补丁 | 读文件、改文件 | 代码和文档修改 |
| Shell | 使用终端 | 搜索、构建、测试、Git 检查 |
| Web Search | 查询外部资料 | 最新文档、发布记录和事实核对 |
| Browser | 操作网页 | 页面流程、DOM、Console、Network |
| Computer Use | 看屏幕并点击 | 没有 API、必须操作图形界面的任务 |
| Appshots | 拍下当前窗口 | 给 Context 一张准确的现场照片 |
| Plugins / MCP | 连接外部服务 | 读取数据或执行外部动作 |
工具数量不是关键。关键是边界清楚、结果可靠、错误可读，高风险动作会停下来。
前端开发为什么需要 Browser 和 Computer Use
只改代码、不打开页面，像修完汽车却不点火。
Browser 可以检查 DOM、CSS、Console、Network 和性能信息。Computer Use 可以操作必须通过鼠标、键盘和屏幕完成的流程。
有稳定 API 或 Plugin 时，优先使用结构化工具；只有界面本身才包含答案时，再用 Computer Use。
第六层：Context、State、Thread 和 Project 各管一层
长任务不能靠模型无限记忆。
| 概念 | 保存什么 |
|---|---|
| Context Window | 这一轮真正送给模型的信息 |
| State | 任务进行到哪里，刚发生了什么 |
| Thread | 一项任务跨多轮的消息和状态 |
| Project | 多个任务共享的目录、文件、规则和来源 |
Project 像工作间，Thread 像一张工单，Context 像这一刻铺在桌上的材料。
文件、Git、项目规则和工具结果保存在模型之外。Runtime 每一轮重新筛选并组装 Context，长任务才可以暂停、恢复和继续。
第七层：运行环境决定动作发生在哪里
| 环境 | 大白话 | 适合什么 |
|---|---|---|
| Local | 在当前桌面直接施工 | 人和 Agent 一起修改当前项目 |
| Worktree | 开一个隔离工位 | 并行尝试，避免污染当前工作区 |
| Cloud | 交给远程工位 | 后台或远程执行 |
这次任务运行在 Local：
/Users/liguwe/832所以文件修改会直接出现在当前工作树。
多 Agent 本质上是多条独立循环。每个任务有自己的 Thread、Context 和 State；需要同时改仓库时，再用 Worktree 隔离文件现场。
难点不在多开几个模型，而在任务拆分、环境隔离、结果汇总和冲突处理。
关于 worktree ，可以参考 精读：一个人如何管理几十个 AI 程序员？
第八层：安全有三道关
| 安全机制 | 管什么 |
|---|---|
| Guardrails / 任务规则 | 这个动作该不该做 |
| Sandbox | 技术上能访问哪些文件、网络和程序 |
| Approval | 高风险或越界动作由谁批准 |
Ask for approval 模式允许常规的 Workspace 读写和本地命令，越过范围时会停下来。Full access 放开的范围更大，风险也更高。
但技术上能做，不代表任务已经授权。这次只允许改文章，没有要求提交、推送或公开发布，所以 ChatGPT 必须停在改写和验证。
第九层：Skill、Plugin、MCP 解决三个问题
| 名称 | 解决什么 | 类比 |
|---|---|---|
| Skill | 这类任务应该怎样做 | 工序卡 |
| Plugin | 怎样安装和分发一组能力 | 工具包 |
| MCP | 外部工具和资料怎样接入 Agent | 标准插口 |
这次任务只需要 new-note Skill 和现有工具。只有任务需要访问当前尚未接入的外部系统时，才需要相应 Plugin 或 MCP 连接。
第十层：Goal 管长任务，人负责纠正和签字
普通问答、一次小修改、几轮内能完成的任务，使用普通 Thread 就够了。
Goal 适合这类任务：
- 需要运行几十轮甚至更久。
- 中途可能暂停，之后还要继续。
- 下一步取决于文件、测试或网页的真实结果。
- 必须持续保存进度，并反复验证是否完成。
例如：升级大型仓库的依赖并修完全部测试、迁移几十个前端页面并逐页验收、收集大量资料后生成完整研究报告。
Goal 不是“更聪明的模型”，而是 Runtime 管理长任务的一种方式。它至少要写清三件事：
| Goal 的组成 | 解决什么问题 | 用本文举例 |
|---|---|---|
| Outcome | 最终环境要变成什么样 | 得到一篇以 ChatGPT 为案例的 Agent 教程 |
| Constraints | 执行过程中不能越过哪些边界 | 使用当前资料、大白话、保留核心、不擅自提交 |
| Verification | 用什么证据判断真的完成 | 检查正文、链接、Mermaid、编号和 diff |
Constraints约束条件、限制条件
这次文章改写可以在普通 Thread 中完成。上面的表格只是用这个熟悉的任务，说明 Goal 应该怎样定义。
Goal 可以暂停、恢复和修改，但不会自动扩大权限。
人也一直在循环里：追加要求、纠正方向、批准高风险动作、检查 diff，并决定是否继续。这篇文章从概念篇和案例篇的拆分，到案例改成 ChatGPT，再到现在删掉啰嗦内容，就是连续的人类反馈。
Human-in-the-loop 不是失败补丁，而是 Agent 产品的正常组成。
第十一层：Trace 和 Eval 负责证明“真的完成”
模型内部怎样想，不是验收证据。真正有用的是可观察的过程和结果：
| 概念 | 这次任务里的证据 |
|---|---|
| Trace | 读了哪些文件、调用了什么工具、哪里报错、补丁改了什么 |
| Output | ChatGPT 最后的完成说明 |
| Outcome | 文件确实变化，目标内容存在，没有越权操作 |
| Eval | 编号、围栏、链接和 diff 检查 |
最终回复类似接口返回 200 OK。文件、diff 和检查结果才是数据库里的真实状态。
Review 面板还可能同时展示用户原有的未提交修改。Agent 必须区分本次修改、已有修改和无关文件，不能把整个 diff 都算成自己的成果。
从前端视角看，界面是一张监督控制台
Agent 产品不只需要输入框和流式文字，还要让用户看见并控制五类状态：
前端至少要回答：Agent 正在做什么、碰了什么、怎样暂停、怎样恢复、结果怎样审查，以及多个任务怎样避免互相污染。
把这次任务连成一张时序图
下面的
官方网站代表 ChatGPT 的官方文章和教程
从用户视角看，是“我提要求，它改文章”。
从系统视角看，是多轮“决定—执行—观察—再决定”。
源码：把主循环压成伪代码
下面不是 OpenAI 内部源码，只是把前面的产品行为翻译成 JavaScript：
async function runAgent(task) {
const state = await loadThreadState(task.threadId);
for (let turn = 0; turn < state.maxTurns; turn += 1) {
const context = await buildContext({
goal: task.goal,
project: task.project,
instructions: await loadProjectRules(),
skills: await loadRelevantSkills(task),
tools: await listAllowedTools(),
history: state.history,
observations: state.recentObservations,
});
const next = await model.decide(context);
if (next.type === "final") {
const evidence = await verifyOutcome(task, state);
if (evidence.passed) {
return { answer: next.answer, evidence };
}
state.addObservation(evidence);
continue;
}
const action = await permissions.check(next.toolCall);
const result = await tools.execute(action);
state.addObservation(result);
await saveThreadState(state);
}
throw new Error("超过最大轮数，停止并交给人处理");
}真正难的不是 for 循环，而是怎样选择 Context、设计工具、限制权限、保存 State、处理错误并验证 Outcome。
模型决定智力上限。Runtime 决定这份智力能否稳定落到真实世界。
最后：把 ChatGPT 还原成 Agent 系统
前面的能力可以拆成三张图。
Agent 怎样完成一轮行动
模型决定下一步，Runtime 执行，再把环境结果送回下一轮。
Runtime 靠什么管理任务
这些能力负责保存进度、限制边界，并让人看见和干预执行过程。
系统怎样判断真的完成
Agent 说“完成”只是 Output。真实环境通过 Eval，才算完成。
最后压成一句话：
ChatGPT 把模型放进真实项目，给它 Context、工具、状态和权限，让它根据行动结果持续工作，再把过程和证据交给人验收。
模型是大脑，Tools 是手脚，Runtime 是神经系统，Project 是工作间，Thread 是工单，Sandbox 是围栏，Approval 是门卫，Trace 和 Eval 是验收记录。
考考你
ChatGPT 为什么不只是一个模型？
模型只决定下一步。完整 Agent 还需要 Context、Tools、Runtime、State、权限、执行环境和验收。
Tool Call 为什么不等于工具执行？
Tool Call 只是模型给出的工具名和参数。Runtime 还要校验权限、真正执行，并把结果放回 Context。
怎样判断问题出在 Prompt、Context 还是 Harness？
目标不清先查 Prompt；材料错误或缺失先查 Context；动作没执行、结果没回填或没验收先查 Harness。
Context、State、Thread 和 Project 有什么区别？
Context 是本轮输入，State 是当前进度，Thread 保存一项任务的连续记录，Project 保存多个任务共享的工作环境。
Guardrails、Sandbox 和 Approval 各管什么？
Guardrails 判断该不该做，Sandbox 限制技术访问范围，Approval 让人批准高风险或越界动作。
Skill、Plugin 和 MCP 怎样区分？
Skill 提供做法，Plugin 打包和分发能力，MCP 连接外部工具与资料。
什么时候值得使用 Goal？
任务需要运行很多轮、保存进度、暂停恢复，并持续根据真实结果验收时。普通问答和小修改使用普通 Thread 即可。
为什么多 Agent 通常需要 Worktree？
不同 Worktree 隔离文件现场，避免多个 Agent 在同一工作区互相覆盖。它解决环境冲突，不增加模型智力。
怎样判断 ChatGPT 真的完成了任务？
检查 Outcome：目标文件是否改变、diff 是否符合范围、验证是否通过、高风险动作是否保持未执行。最终回复本身不是完成证据。