当你第一次接手一个 Agent 代码库时，最容易犯的错误，是直接扎进 prompt 和工具实现里。
更好的方式，是先建立分析顺序。
建议按下面的路径去看：
第一，入口。
先找到系统从哪里开始运行，谁触发一次 run，run 的生命周期是什么。
第二，目标。
看这个系统到底想完成什么任务，成功和失败条件是什么。
第三，输入。
看模型真正吃到的是什么，而不是表面上系统拿到了什么。
第四，状态。
看系统有没有显式状态对象、session、memory、checkpoint。
第五，动作。
看有哪些工具、动作、副作用和权限边界。
第六，循环。
看模型如何决定下一步，循环由代码主导还是由模型主导。
第七，治理。
看是否有 guardrail、approval、trace、eval 和失败恢复。
如果按这个顺序去拆，一个 Agent 系统通常会比你直接读 prompt 清晰得多。
但第 36 章真正想强调的，是：一个 Agent 系统最容易被误读的地方，恰恰就是 prompt。
因为 prompt 通常最显眼、最像“智能中心”，所以很多人一打开代码库就去找 system prompt、tool prompt、planner prompt，结果越读越乱。读到最后，仿佛整个系统就是若干提示词和若干工具拼在一起。事实上，这种阅读顺序往往会把真正决定系统行为的控制面全部读丢。
因此，第 36 章第一条结论应该是：
分析一个现有 Agent 系统，最重要的不是先看模型说了什么，而是先找系统在哪里定义目标、状态、动作、循环和边界。换句话说，分析 Agent 不是“读文本”，而是“找控制面”。
为了避免读乱，可以把阅读顺序压成五个问题。
第一，这个系统从哪里开始，在哪里结束。
也就是它的 run 是如何被触发的，run 的生命周期是什么，成功与失败如何被判定，最终结果交给谁。很多阅读上的混乱，都来自一开始没有把生命周期看清楚。入口不清楚，你就不知道哪些提示词是初始化信息，哪些是中间状态，哪些又只是调试痕迹。
第二，模型真正看到了什么。
这一步尤其容易被误判。系统收到的原始输入，通常并不等于模型实际可见的上下文。很多系统会做清洗、压缩、重排、摘要、检索、工具返回拼接和权限过滤。真正决定模型行为的，并不是“系统大概有这些数据”，而是“这一轮模型到底看见了哪一版对象和哪一版状态”。
第三，系统到底能做什么。
这里不要只看工具数量，而要看动作边界。哪些调用只是读取，哪些会产生副作用，哪些动作必须审批，哪些动作只在特定角色下可用，哪些动作会写回状态层。读 Agent 动作空间时，重点不是功能表，而是副作用与权限结构。
第四，谁在决定下一步。
这是理解 Agent 系统时最关键的一问。很多系统表面上看都是“模型决定下一步”，但实际上控制权可能分散在不同地方：有些由代码决定主流程，模型只填空；有些由模型决定工具选择，但代码决定是否允许执行；有些由规则层决定是否中止、回滚或升级；有些多 Agent 系统还会在 handoff、manager、reviewer、approval hook 之间切换控制权。
如果这一点看不清，你就很难判断这是一个以模型为中心的 loop，还是一个以代码为中心的 workflow。
第五，系统如何被约束和如何被看见。
这一步对应的就是治理面：guardrails、hooks、approvals、tracing、evals、audit、kill switch、timeouts、fallback。很多人分析一个 Agent 代码库时，容易把这些部分当成边缘工程代码跳过，但恰恰是这些部分决定了系统是否真正可运营、可调试、可控制。
所以，第 36 章第二条结论应该是：
读一个 Agent 系统时，prompt 只是行为表面；真正决定系统性质的，是输入如何被整理、状态如何被保存、动作如何被限制、控制权如何被切换、轨迹如何被记录。一旦用这个框架去读，大部分 Agent 系统都会迅速变清楚。
你会发现，所谓“复杂 Agent”，往往无非是在几个位置上做了变化：
- 入口是否多源触发
- 状态是否跨轮保存
- 工具是否有副作用与权限区分
- 决策循环是否显式分层
- 是否存在 handoff 与角色切换
- 是否有 trace、approval 和恢复机制
也就是说，理解一个 Agent 代码库最有效的办法，不是逐文件细读，而是先画出这几个层面的结构图。等结构图出来，再回去看 prompt 和工具实现，很多模糊之处会立即清晰。
这也是为什么 tracing、sessions、persistence、hooks、guardrails、handoffs、authorization 这些文档和代码入口如此重要。它们往往不是辅助说明，而是系统真实控制面的暴露点。
所以，本章最后要留下的判断是：
分析一个现有 Agent 系统，最有效的方法不是“从提示词往外读”，而是“从生命周期、状态、动作、控制权和治理边界往里收”；只有这样，你看到的才是系统，而不是表象。