Anthropic 12 月 19 日发布《Building effective agents》，其中一句和我的工程经验很一致：成功实现更常使用简单、可组合的模式，而不是复杂框架。Agent 架构不是功能越多越好，关键是任务到底需要哪种自由度。

我不会拿一个通用 Agent loop 处理所有问题。路径已知就做 chaining，类别明确就 routing，子任务独立就 parallelization，拆分动态才用 orchestrator-workers，需要反复改进就 evaluator-optimizer，真正开放探索才进入 autonomous agent。

Anthropic 在 11 月 25 日公开 Model Context Protocol（MCP）后，Agent 连接数据和工具终于有了一套开放协议。它解决的核心问题很实际：每个 AI 应用不必为每个数据源重复写私有集成，Server 可以用统一方式暴露 resources、prompts 和 tools。

但 MCP 是连接与能力发现协议，不会替企业完成对象权限、审批、数据分级和副作用治理。我会把 MCP Client/Server 放进现有 Agent Gateway，而不是让发现到的 Server 直接获得执行权。

企业系统通常已经有大量 REST/RPC API，把 OpenAPI 文档转成 function schemas，看起来就能让 Agent 使用。问题是内部 API 是为确定性程序和后台页面设计的：参数宽、状态隐含、错误复杂，调用方默认知道对象 ID 和业务前置条件。模型不具备这些默认知识。

我会在现有 API 外增加 Agent Tool Facade。接口围绕用户目标和安全闭环设计，而不是一一映射 Controller 方法。典型动作拆成 Discover/Resolve、Preview、Execute、Observe、Verify/Compensate。

最小 Agent loop 往往是一段 while true：调用模型，看到 tool call 就执行并把结果放回消息，看到 final answer 就结束。Demo 里足够，生产中只要进程重启、用户确认等十分钟、工具超时但实际成功，内存里的循环就无法给出正确恢复。

我会把 loop 做成持久化状态机。每次模型 attempt、工具 operation、用户等待和最终化都有独立状态，迁移先写事件和 artifact，再推进 current state。重启后从最后一个已提交状态恢复，不从对话文本猜执行到哪里。

Agent 工具多起来后，最初那份 name + description + parameters 列表很快不够用。平台不知道哪个工具有副作用、能否自动重试、需要什么权限、错误如何分类，也不知道 schema 改动会影响哪些 Prompt 和运行中的 Agent。

我把工具注册表做成 Capability Registry。注册项不仅供模型选择，也供路由、策略、执行器、审计和发布系统使用。每个版本不可变，Agent Bundle 固定 registry snapshot，运行中不会看到工具定义漂移。

Agent 出问题后，常见做法是把用户问题再问一次。第二次可能用了新模型、新索引和变化后的工具状态，即使答对，也不能证明原问题修复；如果工具有副作用，直接重跑还可能再次发送、创建或修改。

我把 Trace Replay 分成三层：先用原始事件回放协议转换和状态归并，再用固定检索/工具 fixture 回放编排，最后才在隔离环境调用新模型或新索引。每层回答不同问题，且生产副作用默认不重演。

Agent 评测最容易从“先造 100 道题”开始。题目通常干净、步骤短、工具永远成功，最后测出一个不错的完成率。生产失败却来自另一套分布：权限刚变化、工具 200 但 body 缺字段、流中途断开、两个同名对象、旧 memory 污染了本轮。

我更愿意从真实失败反向建设评测。每个对用户有影响的 Run，先完成证据归因，再抽成最小可复现场景，脱敏审核后加入固定版本的 regression suite。评测集不是一次性题库，而是系统故障经验的可执行资产。

模型能稳定返回 JSON 后，很多 Agent 链路会直接反序列化并调用后端。JSON Schema 确实能挡住缺字段、类型错和非法枚举，但它无法证明 job_id 指向用户想要的任务，也无法证明开始时间早于结束时间、资源仍处于可操作状态。

我把结构化输出看成候选命令。它要经过解析、schema、归一化、业务语义和执行前绑定五层，最后才成为工具可接受的 command。结构正确只是第二层，不是执行许可。