夜雨聆风AI 导读
这个系列从 Codex 的 CLI 源码出发，先后拆了 Turn、工具、权限、沙箱、上下文、Skill、MCP、Hooks、Plan、Compaction、多 Agent、Guardian 和 App Server。
最后回头看，会发现这些模块可以收成五条工程线：任务线让工作持续推进，上下文线让 Agent 看懂现场，动作线把判断落到工具，边界线处理风险，交付线把结果带回人和不同入口。
这篇给前十五篇文章收一个可复用的判断工具。以后你看任何 Agent 产品或准备自己搭一套流程，都可以顺着这张地图检查缺了什么。
第十六篇，把十五个模块收成五条工程线
任务线：Thread、Turn、Plan、状态主干，让一段工作有身份和节奏
上下文线：项目指令、Skill、Compaction，让有限窗口装进必要现场
动作线：工具、Plugin / MCP、Hooks，让模型判断进入真实工作
边界线：审批、沙箱、Guardian，让高风险动作能停下来
交付线：验证、Subagent、协议与状态，让结果能被验收和接续
蓝色是人和目标，绿色是运行系统和上下文，黄色是工具动作，红色是风险边界。
这个系列写到最后，我反而越来越少把注意力放在“模型能不能写代码”上。模型能力当然重要，它决定 Agent 能看多远、想多深。但一旦进入真实工作，用户面对的是另一件事：这项任务能不能持续往前走，能不能控制风险，最后能不能交出一份让人放心的结果。
一开始拆 Codex，我想从源码里找一张 Agent 工程化地图。现在十五个模块都走过一遍，这张地图终于可以收起来。它不复杂，也不需要给每一层起一个很新的名字。把它放回工作里看，就是五个连续的问题：任务怎么开始和持续，Agent 看见什么，动作如何发生，风险由谁控制，结果怎样回到人手里。
这五个问题说清楚了，模型就有机会进入流程。任何一条缺失，Agent 都容易停在演示阶段。
一、先把 Agent 看成一段持续的工作
图 1｜任务线负责把一段工作串起来
Thread：任务现场
目标、历史、环境和状态沿着同一条任务保存下来。
Turn / Plan：工作节奏
每次交入任务后，系统能显示正在做哪一步、下一步准备做什么。
状态主干：可恢复
历史、实时进度和终态按顺序传递，换入口时任务不会断成两段。
很多 Agent 的第一印象是一个更聪明的聊天框。这个印象不算错，但它只能解释任务刚开始的几分钟。任务一旦拉长，用户会追问：刚才做到哪里了，为什么停住了，能不能换个地方继续看，失败以后从哪里重新开始。
Codex 用 Thread、Turn、Item 给这段工作分了层。Thread 保存长期现场，Turn 标记一次工作周期，Item 留下这轮里的动作和结果。Plan 让过程里的下一步能被看见；App Server 再把历史和实时进度送到不同入口。它们合在一起，处理的是同一件事：让任务有身份，有过程，也有终态。
我把这条叫做任务线。团队做 Agent 时，先问的也该是任务线：用户交进来的目标在哪里保存，任务被打断以后如何恢复，过程中每一步是否能被看见。没有这条线，后面的工具再多，也很难形成连续工作。
二、上下文线，决定 Agent 到底看见了什么
图 2｜上下文要分层进入，也要在长任务里整理
项目规则
目录、项目指令、环境与权限，让 Agent 知道当前现场的基本约束。
Skill：复用经验
把重复流程、知识和工具依赖整理成可选用的工作说明。
Compaction：整理记忆
上下文接近窗口时，保留关键事实，让长任务还能继续判断。
Agent 做错事，常常是因为没有看见该看的信息。项目里有哪些规则，当前目录处于什么环境，前面已经试过什么，团队惯用的流程是什么，这些都会改变下一步的判断。
Codex 对上下文的处理给了我一个很稳定的认识：上下文是一种有限资源。项目指令有预算，Skill 目录和正文有预算，历史记录也会接近窗口。系统需要持续决定什么先进入、什么留在外面、什么在长任务里压缩成新的记忆。
这条上下文线，决定 Agent 是在猜，还是在依据项目现场工作。普通团队最先能做的事情也在这里：把高频流程的规则、数据来源、验收口径整理出来，再让 Agent 带着这些材料做一件小事。没有这层准备，模型越快，错误也会越快。
三、动作线，让判断进入工作现场
图 3｜工具、能力包和生命周期事件构成动作线
Tool Calling
把读、写、执行这些动作放进一次可观察的调用链。
Plugin / MCP
把外部能力、连接器、Skill 和相关规则组织成可管理的能力包。
Hooks
在工具前后、权限请求、压缩等节点插入团队自己的规则。
模型会给建议，Agent 要完成工作，还得能把建议变成动作。读文件、改代码、执行命令、调用外部服务，都是模型之外的世界。工具调用链把两边接起来：系统收到一个动作，按规则执行，再把结果带回下一次判断。
做到这里，很多团队会开始疯狂加工具。Codex 的 Plugin、MCP 和 Hooks 反而提醒我们，能力增长需要组织。Plugin 把一组能力放进有身份、有来源的 bundle；MCP 在运行时根据环境、配置和 policy 决定哪些工具可以露出来；Hooks 让规则进入动作发生的节点。
动作线的判断标准很简单：工具要能说明自己从哪里来、当前能做什么、什么时候被调用、结果回到哪里。动作进入工作流以后，还要能被管理。
四、边界线，让系统在该停的时候停下来
图 4｜风险要走一条分层路径
Approval
先判断这项动作是否需要升级确认，用户与自动审查各有入口。
Sandbox
执行范围由文件、网络和系统权限构成实际边界。
Guardian
独立审查精确动作，连续拒绝时会中断错误方向上的尝试。
Agent 工程里最容易被误会的一点，是把风险控制看成“弹出一个确认框”。确认框只是最后一个可见动作。前面还有工具本身能访问什么，当前沙箱允许什么，项目规则是否可信，审批要交给人还是自动审查，拒绝以后任务如何继续。
Codex 把这些判断拆开了。Sandbox 给执行划范围；Approval 负责把需要升级的动作送进相应路径；Guardian 用独立会话审一项精确动作，并且在失败、超时或连续拒绝时让自动放行停下。Hooks 也可以在更早的节点给出团队规则。
这条边界线背后，延续的是软件工程里早就存在的常识：权限、测试、审批和回滚，都是人会犯错时留下的缓冲。Agent 进入流程以后，这些旧秩序依然有用，只是要重新安排到模型和工具之间。
五、交付线，决定一次工作能不能留下来
图 5｜结果要回到人，也要回到任务主线
Verification
改动、测试、命令输出和未完成事项，构成用户验收的材料。
Subagent
分出去的工作要带着边界执行，完成以后把状态和结果还给主线程。
Protocol / State
不同入口看到同一份过程和终态，用户才能继续判断下一步。
前面四条线解决了 Agent 怎么开始、怎么理解、怎么行动、怎么避免越界。交付线回答最后一个问题：这次工作如何变成人能检查、能接手、能继续使用的结果。
验证并不保证所有问题都能被自动发现。它的价值在于把测试、命令输出、diff 和未完成事项摆回用户面前，让人能按交付标准判断。多 Agent 也一样，子任务做完以后，结果必须回到父线程；否则并行只留下很多散落的回答。
最后，App Server 和协议把这些过程状态带到不同入口。用户看到的并不只是一段最后的总结，还包括任务怎么走到这里、现在是否完成、下一步能不能继续。交付线把 Agent 从一次性输出，带回到持续工作的责任里。
六、普通团队从哪里开始，不用一口气搭完地图
图 6｜从交付标准倒推，先跑通一条小工作流
第一步：选一件小事
高频、边界清楚、结果可验证，例如补一类测试、排查一类日志。
第二步：补四条基础线
目标和状态、必要上下文、可用工具、明确边界，先写清楚。
第三步：按交付复盘
看结果、验证、返工和人工介入，再决定扩哪一块能力。
整张地图看起来不小，落地时不需要一次搭全。很多企业 AI 项目做不下去，常常从一个过大的愿望开始：希望 Agent 同时会理解业务、调很多系统、替人做决定、自动完成交付。目标越大，缺失的工程位置越多，最后容易只剩一场演示。
我会反过来做。先选一件高频、边界清楚、验收明确的小工作。把最终交付物写下来，再倒推它需要哪些现场信息、哪些工具、哪些确认、哪些验证。任务线和上下文线先理顺，动作范围先收窄，结果先让人看得懂。跑过几轮以后，再决定要不要接入更多能力或增加分工。
这也是我从 Codex 源码里带走的最实用的东西。好的 Agent 工程，不靠一次把自动化推到最大。它先把每一条线安放到合适的位置，让模型、工具和人各自清楚自己该做什么。
用这张地图看一个 Agent 产品
它有没有清楚的任务身份、过程状态和恢复路径？
它怎样获得项目上下文，又怎样在长任务里处理有限窗口？
工具从哪里来，调用经过哪些规则，结果是否能回到下一次判断？
遇到高风险动作，它能否停下、解释、请人确认，并避免换路绕开？
交付时，用户能否看到验证材料、未完成事项和后续可继续的任务状态？
写完第十六篇，这个系列就先告一段落。我们从 Codex 的开源仓库出发，看到的是 CLI 和本地运行层，最后抽出来的却不只是一套 Codex 的实现细节。任务、上下文、动作、边界、交付，这五条线会反复出现在不同的 Agent 产品和团队流程里。
以后再看一个 Agent，我会少问一句“它有多聪明”，多问几句“它如何工作、如何受限、如何证明、如何继续”。这几句问清楚，很多热闹会自动降下来，值得投入的地方也会慢慢浮出来。
《拆解 Codex：AI Agent 工程化架构实战》完结
第一篇画 Agent 工程地图，第二篇拆 Turn，第三篇拆工具调用链，第四篇拆权限审批，第五篇拆沙箱，第六篇拆验证链路，第七篇拆上下文，第八篇拆 Skill，第九篇拆 Plugin / MCP，第十篇拆 Hooks，第十一篇拆 Plan，第十二篇拆 Compaction，第十三篇拆 Subagent / Multi-Agent，第十四篇拆 Review / Guardian，第十五篇拆 App Server / Protocol / Thread State，第十六篇把它们收成一张 Agent 工程化地图。