Agent 等于 LLM 加上下文加工具，只是工程的起点

Agent = LLM + 上下文 + 工具 很适合解释一个 Agent 由什么组成，却不足以判断它能不能进生产。选一个强模型，塞进业务资料，再接上几个 API，通常能做出演示；任务一旦变长、工具开始改动外部状态，真正决定结果的就不再是这三个名词，而是系统怎样组织它们。

李博杰的《深入理解 AI Agent：设计原理与工程实践》也把重点放在这里。官方仓库以这个公式展开十章，截至 2026-07-29 已列出 93 个配套实验，内容从上下文、记忆和工具延伸到评估、后训练与多 Agent。若只记住开头的公式，却跳过中间的 Harness 工程，反而会错过这本书最有用的部分。

公式列出了零件，没有描述运行时 #

同一个模型和同一组工具，换一套运行方式，效果可能完全不同。系统何时检索资料，工具失败后是否重试，副作用操作由谁确认，长任务如何保存状态，完成后拿什么验证，这些都不在公式里。

书中把 Harness 解释为围绕模型的工程系统。这个视角比“再换一个更强模型”更接近真实问题：Agent 的能力不是一次模型调用的能力，而是模型在特定上下文、工具接口、权限和反馈回路中持续行动的结果。Anthropic 的 Agent 评估文章也采用同样的判断，指出评估对象应是模型与 Harness 的组合，而不是孤立的模型。

因此，一个更完整的工程表达应接近：

Agent 系统 = 模型 + 上下文策略 + 工具合同 + 执行状态 + 权限边界 + 验证反馈

这不是为了发明一个更长的公式，而是提醒团队：前三项让系统“能做事”，后三项决定它“做错时会发生什么”。

上下文不是越多越好 #

上下文包含系统指令、消息历史、工具定义、检索结果和工具返回值。它们都在争用有限的注意力。Anthropic 将 context engineering 定义为对推理期间全部 token 的选择和维护，并建议保留紧凑、高信号的信息；长任务则通过 compaction、结构化笔记和按需读取延续，而不是把全部历史不断追加到窗口。

这也解释了上下文与记忆的区别：

• 上下文解决当前一步应该让模型看到什么。
• 工作状态记录任务进行到哪里、哪些动作已执行、哪些结果待验证。
• 长期记忆保存跨任务仍值得复用、并经过整理的事实和经验。

把聊天记录全部回填，既不是可靠记忆，也不是好的上下文策略。旧错误会跟着进入新一轮，重复材料会挤掉当前证据。更稳妥的做法是只在上下文中保留当前目标、约束、必要证据和最近状态；原始材料留在可检索的外部存储，需要时再读。

MCP 解决接入，不替你治理工具 #

MCP 让客户端用统一协议发现和调用工具，这解决了互操作问题，却没有替应用决定权限、重试和副作用。最新版 MCP Tools 规范仍要求实现方自己处理输入校验、访问控制、限流、输出净化、超时和审计；对敏感操作，客户端应让用户看见工具输入并保留拒绝权。

一个生产工具至少要回答几件事：

1. 输入和输出是否有明确 schema，错误是否可区分、可恢复？
2. 重复调用会不会重复扣款、重复发信或重复删除数据？
3. 读操作与写操作是否分权，敏感动作是否需要确认？
4. 超时之后，系统能否判断操作未执行、已执行或状态未知？
5. 工具结果怎样校验，不能只因为返回了 JSON 就当作成功？

这些问题不会因工具被包装成 MCP Server 而消失。协议描述了“怎样调用”，业务仍要定义“什么情况下允许调用”和“调用后如何确认世界真的变成了预期状态”。

可靠性来自可恢复的执行循环 #

短任务失败，重新问一次也许就够了。长任务涉及多步写操作时，简单重跑可能把问题扩大。系统需要留下可恢复的运行状态：当前目标、已完成步骤、工具调用及结果、外部对象版本、待确认事项和终止原因。

可观测性也不能只保存最终回答。OpenAI Agents SDK 的 tracing 文档把模型调用、工具调用、handoff、guardrail 和自定义 span 放在同一条运行轨迹中，目的就是让开发者知道一次任务具体在哪里偏离。轨迹随后还能进入评估集，把偶发故障变成可复现用例。

这里有一条实用边界：

• 读取、搜索、计算等无副作用动作，可以并行、缓存和重试。
• 发消息、改订单、删文件、发布内容等动作，需要幂等键、版本条件、审批或补偿方案。
• 返回“成功”还不够，关键动作应回读外部状态或通过独立信号验证。

Agent 最危险的状态往往不是明确失败，而是“工具超时，但外部操作可能已经发生”。没有状态记录和核验，模型只能猜。

评估应早于多 Agent 和后训练 #

Anthropic 在《Building effective agents》中建议先从简单方案开始，只在复杂度能证明改善结果时再增加工作流或自主 Agent。这个顺序同样适用于多 Agent 与后训练。

多 Agent 能隔离上下文、并行处理独立问题，也会增加任务拆分、状态同步、冲突裁决和总成本。若单 Agent 的工具合同和验收标准都不稳定，多 Agent 只会生成更多难以解释的轨迹。后训练也一样：没有稳定失败样本时，团队甚至不知道应该训练模型，还是修工具描述、上下文选择和运行时。

评估不必一开始就做成庞大平台。先从真实任务建立一个小集合，每条用例至少包含初始状态、允许的工具、成功条件和禁止副作用。除了最终答案，还应记录任务成功率、错误工具调用、人工接管、执行时间、token 与外部调用成本。涉及写操作时，最终环境状态应进入评分，不能只看语言是否通顺。

一条更稳的建设顺序 #

第一步先把任务收窄：输入是什么，完成状态是什么，哪些情况必须停下来问人。第二步用最简单的 prompt 或固定工作流跑通，建立真实样例。第三步再接工具，同时补齐 schema、权限、超时、幂等和结果校验。第四步保存轨迹，把失败转成回归用例。只有这条单 Agent 链路已经稳定，才有理由引入长期记忆、多 Agent 或后训练。

按照这个顺序读《深入理解 AI Agent》也更有效：先读基础、上下文、记忆和工具，再用 Coding Agent 与评估章节检验执行链；多模态、多 Agent 和后训练放到具体需求出现之后。93 个实验的价值不在于全部跑一遍，而在于帮助你定位瓶颈究竟在模型、上下文、工具，还是 Harness。

Agent = LLM + 上下文 + 工具 仍然是一个好入口。只是做工程决策时，还要继续追问：状态如何保存，权限如何收紧，失败如何恢复，结果如何验证。答不上来时，系统还只是一个会调用工具的模型，不是可以承担责任的 Agent。

来源 #

• 《深入理解 AI Agent》官方仓库与在线阅读（十章目录、93 个配套实验、Harness 与评估内容，复核于 2026-07-29）。
• Anthropic：Building effective agents（先使用简单组合、以评估证明新增复杂度）。
• Anthropic：Effective context engineering for AI agents（上下文预算、按需读取、压缩和结构化笔记）。
• Anthropic：Writing effective tools for AI agents（工具边界、返回内容与评估方法）。
• Anthropic：Demystifying evals for AI agents（把模型与 Harness 作为整体评估）。
• Model Context Protocol：Tools specification 2026-07-28（输入校验、访问控制、确认、超时和审计要求）。
• OpenAI：Agents SDK integrations and observability（工具接入、运行轨迹与评估衔接）。