第 3 章 Agent 的系统视角¶

前两章分别回答了两个基础问题：什么是 Agent，以及一个 Agent 为什么能够工作。到这里，读者通常会形成一个初步印象：Agent 似乎是由模型、Prompt、Tools、Memory 等若干模块拼成的系统。这个印象不算错，但还不够。因为只看模块名称，很容易把 Agent 理解成静态组件集合，而忽略它真正重要的地方并不在“有哪些部件”，而在“这些部件如何围绕任务闭环组织起来”。

因此，本章要切换到系统视角，回答三个问题：

从系统运行过程看，一个 Agent 到底经历了哪些阶段。
在这个过程中，哪些信息在流动，哪些状态在变化。
为什么同样使用大模型，不同 Agent 系统的稳定性会差这么多。

3.1 输入、上下文、决策、动作、反馈闭环¶

理解 Agent 的最好方式之一，是把它放回一个完整的控制回路中去观察。对于大多数任务型 Agent 而言，系统通常会经历如下几个基本阶段：

第一步是接收输入。这个输入未必只是用户的一句话，它可能还包括用户身份、会话历史、任务上下文、外部事件、已有计划以及系统策略。很多时候，用户真正想解决的问题并不完整地写在当前输入里，而是分散在一组背景信息中。

第二步是构造上下文。系统需要判断哪些信息应该交给模型，哪些信息应该先保留在状态层，哪些信息需要通过检索或工具临时补充。上下文并不是对输入的原样拼接，而是一种面向当前决策的装配过程。这个阶段的质量，往往直接决定模型后续判断的稳定性。

第三步是做出决策。模型或控制器需要在当前状态下判断下一步应该采取什么动作。这个动作可能是直接回答，也可能是提问澄清、调用工具、拆分任务、触发工作流或请求人工确认。这里的关键不是“生成一句看起来合理的话”，而是“选择一个能真实推进任务的动作”。

第四步是执行动作。只有当决策真正落到外部环境中，Agent 才算开始推进任务。执行动作可能意味着查询数据库、读取文件、访问 API、运行代码、写入系统记录，或者把任务转交给另一个 Agent 或人工角色。执行阶段把系统从“思考”带入“行动”。

第五步是读取反馈。动作执行后的结果会改变系统状态。这个结果可能是查询返回、错误码、文档片段、代码 diff、状态变更，也可能是用户补充信息或人工审批结论。Agent 必须把这些反馈纳入新的上下文，否则任务只能停留在单步响应。

第六步是更新状态并进入下一轮决策。如果目标尚未完成，系统就会根据反馈继续推进闭环；如果目标已经完成，系统则应在合适的层次上输出结果、记录状态、触发收尾动作，必要时还要更新记忆或写入审计日志。

从这个角度看，Agent 并不是一个“回答生成器”，而更像一个围绕任务推进运转的控制系统。它的核心不是某一次推理，而是多轮决策与反馈之间的连续耦合。

flowchart LR
    A["输入"] --> B["上下文装配"]
    B --> C["决策"]
    C --> D["动作执行"]
    D --> E["反馈"]
    E --> F["状态更新"]
    F --> B

工程提示¶

当一个 Agent “看起来不稳定”时，问题往往不在某一步，而在整个闭环里某个环节没有被系统化设计，例如反馈没有进入下一轮决策，或者状态没有被可靠更新。

3.2 Agent 的最小可用架构¶

虽然不同场景下的 Agent 差异很大，但如果只追求一个最小可用形态，仍然可以抽象出一套相对稳定的骨架。这个骨架至少包含五类部件。

第一类是入口层。它负责接收任务请求，并把请求转换成系统可处理的统一输入形式。这个入口可以是聊天界面、API、命令行、Webhook 或定时任务。入口层本身并不负责智能决策，但它决定了任务是如何进入系统的。

第二类是上下文装配层。它负责把当前任务所需的信息组织成可供模型使用的输入，包括系统指令、任务目标、历史状态、工具描述、知识检索结果以及环境约束。很多 Agent 的效果差异，本质上就是这层设计能力的差异。

第三类是决策层。这里通常由大模型承担主要推理工作，但也可能配合规则、状态机、策略路由器等机制共同完成。决策层输出的核心不是最终答案，而是“下一步动作建议”。

第四类是执行层。它负责把决策转换成真实动作，并与外部系统交互。执行层包括工具调用器、权限校验、超时控制、重试策略、错误处理以及动作结果标准化等机制。

第五类是状态层。它负责维护任务执行过程中产生的中间信息，包括任务阶段、已完成动作、失败记录、用户偏好、长短期记忆和审计信息。没有这一层，Agent 很难在多步任务中保持一致性。

把这五层串起来，一个最小可用 Agent 大致可以描述为：

入口 -> 上下文装配 -> 决策 -> 执行 -> 状态更新 -> 下一轮决策

flowchart TB
    A["入口层"] --> B["上下文装配层"]
    B --> C["决策层"]
    C --> D["执行层"]
    D --> E["状态层"]
    E --> B

需要注意的是，这个“最小可用架构”并不意味着系统简单。相反，它只是说明任何可持续演进的 Agent，至少都需要把输入、决策、行动和状态这几个核心面清楚拆开。很多原型系统之所以后面难以维护，就是因为一开始把这些职责全部塞进了一个 Prompt 或一个单函数里。

工程提示¶

原型阶段允许把多层逻辑压在一起，但一旦系统要走向生产，就必须尽早把“上下文装配”“动作执行”“状态维护”从 Prompt 里拆出来。

3.3 单 Agent、多 Agent、工作流系统的边界¶

从系统视角继续往下看，另一个常见问题是：什么时候一个 Agent 就够了，什么时候需要多个 Agent，什么时候反而应该退回传统工作流？

单 Agent 的优势在于结构简单、上下文统一、调试成本低。对于很多中等复杂度任务来说，只要模型能够在有限步骤内完成判断和工具调用，单 Agent 往往是首选。它特别适合以下场景：

任务目标单一。
工具数量有限。
执行链路不长。
状态主要围绕当前任务展开。

但当任务开始出现明显的角色分化时，单 Agent 的负担会迅速上升。例如既要做高层规划，又要做底层执行，还要做审查和仲裁，这会导致上下文不断膨胀，职责边界变得模糊，调试时也很难判断问题究竟出在规划、执行还是评估阶段。这个时候，多 Agent 才开始有意义。

多 Agent 并不是“把一个 Agent 复制很多份”，而是把不同职责显式拆开。例如：

Planner 负责拆解任务与生成策略。
Executor 负责调用工具和推进执行。
Reviewer 负责检查结果质量和约束满足情况。
Coordinator 负责仲裁、重试和结果汇总。

这种拆分的前提是：角色之间的边界足够清晰，通信协议足够稳定，拆分带来的收益大于额外协调成本。否则，多 Agent 只会把原本就复杂的问题进一步放大。

而传统工作流系统仍然有自己非常明确的位置。当任务主链路本质上是稳定的、可枚举的、可审计的，那么最合理的做法往往不是让 Agent 接管整个流程，而是让工作流负责主干控制，并在其中某些不确定节点调用 Agent。例如：

客服系统中的复杂问答节点。
运维系统中的故障原因分析节点。
文档处理链路中的信息提取与归纳节点。

工程上最常见、也最务实的形态，并不是“纯 Agent 系统”，而是“Workflow 托底 + Agent 增强”的混合架构。

工程提示¶

如果一个团队在还没有把单 Agent 做稳定之前就开始讨论多 Agent，通常不是设计超前，而是问题分解还不够扎实。

3.4 Agent 系统中的信息流与状态流¶

很多软件系统可以只关注控制流，但 Agent 系统如果只看控制流，往往不够。因为在 Agent 中，真正难管理的常常不是步骤顺序，而是信息如何进入、停留、变形和退出系统。

首先是信息流。用户输入、知识检索结果、工具返回值、系统提示、任务计划和历史摘要，都会在不同阶段进入模型上下文。它们不是静态共存，而是在每一次决策中被重新选择、压缩和重组。信息流设计决定了模型看到什么，也就决定了模型最可能做出什么判断。

其次是状态流。每一次工具调用、每一条中间结论、每一个失败原因、每一次人工介入，都会改变系统所处状态。状态流设计决定了 Agent 是否知道“自己已经做到哪里了”，以及“下一步到底应该继续、回滚还是终止”。

再次是动作流。动作不是凭空发生的，它必须穿过权限检查、参数校验、工具封装、外部系统执行和结果标准化这些层次。动作流设计的质量，直接影响 Agent 的安全性和可观测性。

最后是反馈流。Agent 系统能否持续收敛，依赖的不只是模型能力，还依赖反馈是否能够被系统吸收。一次失败的工具调用，是仅仅显示给用户，还是写入状态等待重试？一次人工纠偏，是当场生效，还是沉淀进记忆或评测系统？这些都属于反馈流设计的一部分。

理解这几种流动关系后，读者会更容易看清一个事实：Agent 难就难在它不是单次推理系统，而是多种流同时存在并相互作用的系统。

3.5 为什么 Agent 更像控制系统，而不是模板系统¶

传统模板系统的核心逻辑是：输入满足某些条件，就触发对应模板或规则，再产出结果。它依赖的是规则覆盖率与分支设计质量。Agent 则不一样。它面对的是部分未知任务、非结构化输入和动态外部环境，因此更接近控制系统。

控制系统关注的是：

当前状态是什么。
目标状态是什么。
现在可以采取哪些动作。
动作会带来什么反馈。
如何根据反馈不断修正路径。

把 Agent 理解为控制系统有几个直接收益。

第一，它会促使你更重视状态建模，而不是只写 Prompt。

第二，它会让你更自然地引入失败恢复、幂等控制、人工介入和终止条件，因为这些本来就是控制系统设计的一部分。

第三，它会让你从一开始就意识到：Agent 的问题不只是“回答质量”，还包括“是否可控、是否可审计、是否能中断、是否可恢复”。

这也是为什么很多看起来“文本效果不错”的系统，一旦真的进入生产环境就暴露出各种问题。因为它们被设计成了模板增强器，而不是任务控制系统。

3.6 本章小结¶

从系统视角看，Agent 的本质并不是若干能力模块的堆叠，而是一个围绕输入、上下文、决策、动作、反馈持续运转的任务闭环。任何一个可用的 Agent 系统，至少都需要解决四件事：如何组织上下文，如何做动作决策，如何与外部环境交互，以及如何维护状态并吸收反馈。

当读者开始用这种视角观察 Agent，就会发现很多后续问题都会自然落位：Prompt 属于上下文装配的一部分，Tool Use 属于动作执行系统的一部分，RAG 和 Memory 属于知识与状态系统的一部分，而评测、可观测性和安全则是保证这个闭环长期稳定运行的支撑层。

下一章会在这个基础上继续往前走，讨论一个更具体的问题：当我们真正开始落一个 Agent 时，系统中的 Model、Prompt、Tools、Memory、Knowledge 和 Runtime 这些角色，应该如何分层与协作。