如果把研究和工程放在一起看，最后最值得保留的一条最佳实践，其实非常朴素：
不要把 Agent 做成一段万能 prompt。
先把任务世界和业务世界显式建模成结构化系统，
再让模型在这个结构中进行受控自治。这条结论为什么重要？
因为它同时回答了研究和工程两个方向的问题。
对研究来说，它解释了为什么工具、规划、记忆、benchmark、安全和工作流不断成为核心主题。
对工程来说，它解释了为什么真正能落地的 Agent，最后都会回到：
- schema
- state
- tool contract
- routing
- policy
- eval
- approval
因此，这条最佳实践不是某一篇论文提出的技巧，而是一种跨研究、跨产品、跨工程场景的共同收敛。
但如果真要把它写成一句可执行的话，还需要再往前走一步。
因为“结构化系统”这个说法本身仍然太抽象。真正有用的，不是认同这个方向，而是知道这条最佳实践到底在要求什么设计顺序。
第 35 章想给出的，不是很多条建议，而是一条可以覆盖研究和工程的总方法：
先显式建模任务世界，再把模型放进这个世界里；
先定义边界和契约，再授予自治；
先让系统可验证，再让系统更聪明。这条方法之所以重要，是因为它同时解释了研究为什么收敛到某些方向，也解释了工程为什么最终总会回到某些对象。
如果从研究侧看，这条最佳实践解释了为什么工具、状态、workflow、benchmark、trace、approval、safety 和 process supervision 会越来越重要。因为一旦任务进入真实环境，模型就必须依赖这些外部结构才能稳定行动。
如果从工程侧看，这条最佳实践解释了为什么真正能落地的系统最后总会回到 schema、state、tool contract、routing、policy、eval 和 approval。因为一旦进入生产环境，系统就必须能被解释、被限制、被回放和被恢复。
因此，第 35 章第一条结论应该是：
被研究和工程共同支持的最佳实践，不是“让模型更自由”，而是“先把世界建出来，再让模型在其中受控自治”。这里的“把世界建出来”，至少包括五件事。
第一，把任务对象显式化。
不要让模型在模糊描述里猜世界，而要把它会接触的对象、字段、关系、状态和约束显式做成 schema。只要对象没被显式化，后面的工具、记忆、审批和评测都会悬空。
第二，把动作空间显式化。
模型能做什么、不能做什么，哪些动作有副作用、哪些只是查询，哪些可以自动执行、哪些必须升级到人，这些都必须先于模型被明确。否则所谓自治，本质上只是未定义边界下的试错。
第三，把状态流转显式化。
输入如何进入模型，可见上下文如何整理，中间结果写到哪里，哪些状态可以长期保存，哪些必须短期存在，异常时如何回滚，这些都决定系统是不是一个真正可运营的 Agent，而不只是一个会说话的壳。
第四，把验证机制显式化。
一个结构化 Agent 不会把“模型说自己完成了”当成完成，而会尽量把完成条件外化为终态验证、工具返回、规则校验、审批节点和轨迹评分。也就是说，判断成功的权力不应完全留在模型内部。
第五，把治理边界显式化。
谁授权、谁审批、谁可见、谁负责，哪些步骤要 trace，哪些操作必须确认，哪些异常必须停机，这些治理对象如果不被显式写出来，系统再聪明也不可能真正可信。
于是，这条最佳实践看上去像一句设计原则，实际上是一套顺序原则。
很多失败项目的根源，不是它们不懂工具、不懂多 Agent、不懂 RAG，而是它们的设计顺序是反的：先让模型尽可能多做事，再想办法补边界。这样的系统当然也能做出 demo，但一进入真实环境，就会在状态、权限、评测和治理上持续失血。
而更稳的顺序则是反过来的：先定义任务世界，再定义动作边界，再定义状态与验证，最后再让模型进入。这样做的系统，模型能力越强，收益越大；模型能力不够强，也不会立刻失控。
因此，第 35 章第二条结论应该是：
最佳实践真正保护的，不是某一次任务成功率，而是系统在模型波动、环境扰动和任务增长下仍然可持续演化。这也是为什么这条最佳实践可以同时被研究和工程支持。
研究支持它，是因为大量 benchmark 和论文都在说明：没有结构，复杂环境中的成功率无法稳定；没有评测，改进无法归因；没有过程对象，安全和恢复无法成立。
工程支持它，是因为大量真实系统都在说明：没有 schema、state、tool contract、policy 和 eval，系统即使短期可用，也很难长期维护，更不可能规模化。
所以，本章最后要留下的判断是：
如果只能留下一个关于 Agent 的最佳实践，那就是：不要把 Agent 做成一段万能 prompt，而要把它做成一个有对象、有状态、有动作、有验证、有治理的受控任务系统。