从零设计 Agent，最常见的错误是从“模型能做什么”开始。
更稳的顺序应该是：
第一步，定义业务目标。
明确这个 Agent 到底要推进什么，不要一开始就把目标写成“做一个万能助手”。
第二步，定义业务对象和业务规则。
先把世界建出来，再谈模型怎么进入。
第三步，定义动作空间。
明确 Agent 能做什么、不能做什么、哪些动作有副作用。
但如果把这三步只看成一个产品设计 checklist，还是不够。
第 37 章真正要解决的是：一个生产级 Agent 的设计顺序到底应该是什么，为什么这个顺序不能颠倒。
很多团队一开始做 Agent，会从“模型能不能完成这项任务”出发。这个起点并非完全错误，但它有一个根本问题：它会让系统设计被模型能力牵着走。结果往往就是，团队先把自治做大，再在后面补权限、补状态、补审批、补评测、补恢复。这样的系统也许能很快出 demo，但几乎一定会在生产环境里付出高额返工成本。
更稳的顺序应该是反过来的。
因此，第 37 章第一条结论应该是：
从零设计生产级 Agent，正确的起点不是“模型会什么”，而是“业务世界长什么样、哪些动作允许被代理、哪些边界必须被保留给系统和人”。把这个顺序展开，可以压成七步。
第一步，定义业务目标，不要定义幻想目标。
“做一个万能助手”不是目标，“把用户支持工单分诊并生成可审阅的解决建议”才是目标；“做一个 coding agent”不是目标，“在受限仓库中定位 bug、修改代码、运行测试并提交待审补丁”才是目标。目标一旦不具体，后面的对象、动作、评测和治理都会失焦。
第二步，定义业务对象和业务规则。
这一步的关键，是先把任务世界显式化。有哪些对象，哪些字段，哪些状态转换，哪些例外情况，哪些规则绝不能由模型自行发明，哪些规则必须外部程序化检查。一个生产级 Agent 的第一块地基，不是 prompt，而是对象模型。
第三步，定义动作空间，而不是直接接很多工具。
工具越多不等于能力越强。真正要先定义的是动作语义：读、写、删、触发、审批、外发、支付、修改配置、执行脚本，这些动作的后果完全不同。动作空间一旦没有先被风险化分层，后面所有权限控制都会变成事后补救。
第四步，定义状态模型与上下文契约。
Agent 看到什么、记住什么、把什么写回哪里、多久保留、何时失效、谁可以覆盖这些状态，这些都要先于具体 prompt 被明确。生产级系统最常见的问题，不是模型不够聪明，而是上下文脏、状态乱、记忆不可控。状态模型不清晰，Agent 很快就会变成“每一轮都在不同世界里工作”的系统。
第五步，定义控制流与角色边界。
哪些步骤由代码固定，哪些步骤交给模型决定，哪些步骤允许 handoff，哪些步骤必须经过 verifier 或 reviewer，哪些步骤必须暂停等审批，这些都应该在设计阶段先确定。也就是说，控制权应该是一开始就被分配的，而不是系统跑起来之后再逐渐补出来的。
第六步，定义评测与治理，再定义优化。
这是很多团队最容易做反的地方。生产级 Agent 不应该先追求“平均成功率看起来不错”，再去想怎样评测；而应该先定义：
- 成功如何被外部验证
- 失败如何被归因
- 哪些指标必须长期追踪
- 哪些步骤需要 trace
- 哪些动作必须审批
- 哪些异常需要人工接管
只有这些问题先有答案，后面的优化才不会把系统推向不可控。
第七步，最后才是模型与运行经济学选择。
到了这一步，再去问：哪一步需要大模型，哪一步可以小模型，哪些上下文需要长窗口，哪些可以压缩，哪些任务要同步，哪些要异步，哪里该缓存，哪里该 fallback。模型选择应该服务于任务系统，而不是反过来定义任务系统。
因此，第 37 章第二条结论应该是：
生产级 Agent 不是“模型 + 工具”的组合，而是“目标、对象、动作、状态、控制流、治理和模型”按顺序叠起来的系统。一旦顺序正确，很多设计决策都会自然清楚。
例如，你不会一开始就纠结要不要多 Agent，而会先问：这个任务是否真的存在可分离角色。 你不会先接几十个工具，而会先问：哪些动作值得被代理，哪些动作必须保留给人。 你不会先调 prompt，而会先问：模型看见的上下文是否已经是可用对象，而不是原始噪声。 你也不会先追求更强能力，而会先问：这个系统是否已经可验证、可恢复、可审计。
这也是为什么真正成熟的 Agent 设计，看起来很少有“炫技感”，反而很像一套克制的系统工程。它知道哪些能力该放给模型，哪些边界不能放；哪些步骤应该自动化，哪些步骤宁可保守一些。
所以，本章最后要留下的判断是：
从零设计生产级 Agent，最重要的不是找到一个足够强的模型，而是按正确顺序把任务世界、动作边界、状态契约、控制流、治理机制和评测体系先搭起来；模型只是最后进入这套结构的执行体。