如果前面几章解决的是“Agent 依赖什么能力”，那么系统层真正要解决的问题就是：
这些能力到底如何被组织起来。
这正是 Agent 和普通模型接入最大的分水岭。
一个普通模型调用，通常只需要处理三件事：输入、prompt、输出。系统当然也可能有很多工程细节，但从功能定义上，它仍然像一次请求响应。
而一个 Agent 不一样。只要它要跨多步完成任务，要在中间调用工具，要读取外部环境，要把上一步结果带到下一步，要在失败后继续做决策，它就已经不再是“单次提示词”，而是一个运行系统。
这不是夸张，而是定义上的变化。
因为从这一刻开始，系统要处理的就不再只是文本生成，而是：
- 状态如何保存
- 工具如何调用
- 回传结果如何进入下一轮
- 什么条件下停止
- 失败后如何恢复
- 多个角色如何交接
- 整个过程如何追踪、评测和治理
这些东西，任何一项都不是 prompt 本身能独立承担的。
所以，第 16 章最重要的结论非常简单：
Agent 不是一个 prompt 的升级版，而是一个把模型嵌进状态、动作、反馈与治理闭环里的系统。
为什么很多人会把 Agent 误解成“更复杂一点的 prompt”？
因为在最初阶段，很多 agent demo 的外观确实像 prompt engineering：给模型更多上下文，告诉它分步思考，给它几个工具描述，再让它循环调用几次。于是很多人就会自然地以为，Agent 只是“prompt 写得更长、规则写得更细”。
但这种理解一旦进入真实工程，很快就会失效。
因为你会立刻碰到这些问题：
- 上一步调用工具得到的结果放在哪里
- 多轮任务中间状态如何保存
- 如果工具调用失败，要不要重试、怎么重试、谁来判断是否继续
- 如果任务需要多人协作或多 Agent 分工，交接点如何定义
- 如果输出错了，到底是模型错、工具错、状态错还是路由错
- 上线后如何知道系统在哪个节点退化了
这些问题都不是 prompt 文案问题，而是系统结构问题。
也正因为如此，今天几乎所有主流平台在谈 agent 时，已经不再只谈 prompt。它们谈的是 primitives、runtime、workflow、memory、tools、guardrails、handoff、tracing、evals。换句话说，官方已经在用软件系统的语言定义 Agent，而不是用提示词的语言定义 Agent。
这一点非常重要。因为它意味着“系统层”不是我们额外补上的工程细节，而是 Agent 这个概念本身的一部分。
要真正理解这一点，可以先看 Agent 至少包含哪些核心层。
第一层，是入口层。
Agent 不是直接面对“世界”，而是从某个入口被触发。这个入口可能是用户消息、定时任务、事件流、工单、业务记录、网页操作、外部 API 或另一个 Agent 的 handoff。不同入口决定了系统最初拿到什么信息、以什么身份开始、带着什么任务目标进入循环。
第二层，是上下文层。
模型永远只看到被系统整理过的上下文，而不是完整现实。所以，什么被放进上下文、以什么顺序放、哪些被压缩、哪些被丢弃、哪些作为长期记忆检索出来，这些都不是模型自己能决定的，而是系统对信息的组织能力。
第三层，是状态层。
这是 Agent 和 prompt 最大的结构差异之一。单次 prompt 可以假装没有状态，因为它只处理眼前这一轮；Agent 不行。只要任务跨步，就会出现 pending decision、tool result、intermediate artifacts、plan progress、session identity、memory pointers 等状态对象。没有状态层，Agent 只能在每一步都重新“假装第一次见到问题”，要么成本爆炸，要么行为混乱。
第四层，是决策层。
这是模型最接近“智能核心”的部分。它负责在当前上下文和状态下决定下一步做什么：继续问问题、调用工具、修改计划、写入结果、切换角色、请求人工确认，或者结束任务。注意，这里已经不是“生成一段文本”这么简单，而是在生成下一步动作。
第五层，是工具层。
一旦系统接工具，Agent 就从语言系统进入动作系统。工具不是“给模型多一个描述文本”，而是一个真实 contract：有哪些工具、谁能调、参数结构如何、调用是否成功、错误如何返回、结果如何写回上下文。这些都必须由系统管理。模型只能提出调用意图，真正执行与回传的是外部运行时。
第六层，是执行层。
工具调用不等于工具执行。执行意味着 shell 命令真的跑了、数据库真的查了、网页真的点击了、文件真的改了、API 真的返回了。只要进入执行层，系统就必须处理超时、异常码、幂等性、副作用、权限和沙箱，这些都已经完全超出 prompt 工程的范畴。
第七层，是反馈层。
Agent 系统的关键不在“一次决定对不对”，而在能否在回传后继续修正。工具成功了，下一步怎么推进；工具失败了，是否重试；环境反馈与预期冲突时，是否重规划；输出被 judge 或规则判错后，如何回到前一步。这些都要求系统具备显式反馈闭环，而不是只会“重新问一次模型”。
第八层，是治理与观测层。
如果一个系统做了这么多事，却没有 trace、logs、trajectory eval、alerts、权限记录、人工审批节点和回放能力，那它即使能跑，也很难运维。Agent 的很多问题不是“最终答案不对”这么简单，而是某个中间节点开始偏了。没有可观测性，你甚至无法知道偏在哪里。
到了这里，Agent 为什么不是 prompt，应该已经很清楚了。
因为 prompt 只能描述意图，系统才能承担流程。
事实上，近年很多官方与论文都在不断强化这一点。像 ReAct、Reflexion、Voyager 这类经典工作之所以重要，不是因为它们教模型“更会想”，而是因为它们把模型放进了“观察-决策-行动-反馈”的循环里。它们关心的已经不是单次回答，而是整个闭环如何推进。只要进入这种结构，系统就天然需要状态、动作空间、错误恢复和反馈回流。
同样，今天各家官方 SDK 和平台都在把 Agent 拆成显式原语：agent、tools、sessions、memory、handoffs、guardrails、tracing、workflow runtime。这个趋势非常说明问题。因为如果 Agent 真的只是 prompt，平台根本不需要抽象出这些对象。
它们之所以存在，恰恰因为真实 Agent 要处理的是运行问题，而不是措辞问题。
这里尤其要强调状态与记忆的重要性。
很多人最初以为，多轮 Agent 只要把历史对话不断拼接回 prompt 就可以。这种做法在简单 demo 里还能勉强工作，但一旦任务变长，就会遇到三个问题：上下文窗口有限、长上下文会退化、历史 token 会持续计费。更关键的是，历史消息本身并不等于系统状态。一个任务走到哪一步、哪个工具已经成功、哪个字段待确认、哪个结论是临时的，这些都需要结构化状态，而不是散落在聊天记录里的自然语言。
所以，一个真正可用的 Agent，必须拥有显式会话对象、线程状态、短期记忆、长期记忆、检索和压缩策略。这些都不是“把 prompt 再写长一点”能替代的。
再看工具与执行。
只要系统说自己是 agent，就基本意味着它不只是回答，还会做事。可一旦要做事，问题马上从“语言生成”变成“动作协调”。模型可以说“现在调用这个工具”，但系统必须负责真正执行这个工具、读取结果、标记是否报错、决定是否继续、把结果回写到后续上下文。没有这个运行时协议，tool use 只是一种幻觉。
这也是为什么官方文档会把 tool_result、function_call_output、暂停续跑、超时控制、审批、沙箱这些东西写得非常具体。因为它们都是系统契约，不是语言风格。
再进一步，Agent 为什么还需要 tracing 和 eval？
因为 prompt 的质量可以主要通过输出样例来感知，而 Agent 的失败往往发生在过程里。也许最终答案错了，但真正的问题可能是：
- 路由把请求分错了
- 某个工具参数传错了
- 某一步状态没有更新
- 某个 handoff 丢了上下文
- 某次重试覆盖了有效结果
- 某个 guardrail 误拦截了本来正确的动作
如果没有 trace 和 trajectory eval，你只能看到“结果不好”，却看不到“系统哪里坏了”。这正是 Agent 需要可观测性的根本原因。
所以，从运维视角看，Agent 更像一个小型分布式系统，而不是一个提示词模板。它有运行时、有状态流、有接口边界、有失败传播链、有回归风险，也需要监控、日志、回放和评测。
这也解释了为什么很多“只靠 prompt 堆出来的 agent”很难长期演化。
这类系统通常会逐步退化成：
- prompt 里塞越来越多业务逻辑
- 代码里塞越来越多兜底补丁
- 工具说明越来越长但选择越来越混乱
- 状态信息散落在消息历史里
- 出错后只能粗暴重试
- 一旦结果不对，几乎无法定位是哪一步错了
短期看，这样的系统也许能跑；长期看，它很难维护，更难规模化。
真正成熟的方向恰恰相反：把系统层显式化。
显式入口、显式状态、显式工具 contract、显式 loop、显式停止条件、显式反馈回流、显式 handoff、显式 trace 和显式 guardrails。只有这样，Agent 才会从“一个会多轮说话的模型”变成“一个可被设计、评测和运营的系统”。
所以，第 16 章最终要建立的结论是：
Agent 不是 prompt 上加一点技巧，而是把模型嵌入一个带状态、带动作、带执行、带反馈、带观测、带治理的运行闭环。只要系统要跨步做事，这个结论就不可回避。