Agentic AI 系统：从“会回答”到“能完成任务”的架构、协议与治理

本文根据 Dwivedi 等人在 Global Business and Organizational Excellence 发表的综述文章《Agentic AI Systems: What It Is and Isn’t》整理，并结合工程实践做了面向开发者的改写。论文中的行业预测、案例和数据均保留其原有语境，不代表本文对未来结果的保证。

摘要

生成式 AI 擅长根据提示词生成文本、图片或代码，但通常不会持续记住目标，也不会主动调用多个系统把一件事情做完。Agentic AI（智能体式 AI）试图补上这一段能力：系统接收一个高层目标后，自主拆解子任务、规划执行顺序、调用工具、保存中间状态，并根据环境反馈修正计划，直到目标完成或被人工中止。

这意味着 AI 的输出单位正在从“一个回答”转向“一个可验证的工作流”。本文从架构、通信协议、能力边界和治理要求四个方面介绍 Agentic AI，并给出一个适合企业内部试点的落地路径。

关键词： Agentic AI、AI Agent、多智能体、LLM、MCP、A2A、持久化记忆、工具调用、AI 治理

1. 先把三个概念分清楚

1.1 生成式 AI：输入提示词，生成内容

典型的生成式 AI 是“提示词 → 模型 → 输出”的流水线。模型可以写文案、生成代码、总结文档或制作图片，但每次调用主要依赖当前上下文窗口；模型不会天然拥有跨会话的长期记忆，也不会在输出后继续观察结果并自动纠错。

因此，生成式 AI 的主要产物是数字内容，人类仍然负责决定下一步做什么。

1.2 传统 AI Agent：一个代理完成一个边界明确的任务

传统 AI Agent 通常是单一程序，使用 LLM、规则、提示词链和少量工具，在限定领域内执行任务，例如邮件分类、企业搜索或客服问答。它可以具备一定自主性，但任务范围、流程和可用工具通常由开发者预先定义，记忆多为短期上下文。

1.3 Agentic AI 系统：多个能力模块围绕目标持续协作

论文给出的核心判断不是“用了 LLM 就是 Agentic AI”，而是系统是否具备一组协同机制：

• 目标驱动： 接收高层目标，而不是只响应单次问题。
• 审慎规划： 把目标分解为可执行的子任务，并动态调整顺序。
• 持久化记忆： 保存用户偏好、历史交互、环境状态和中间结果。
• 工具增强推理： 通过 API、数据库、检索系统或企业软件执行动作。
• 多智能体协作： 让规划、检索、编码、评估等专长 Agent 分工合作。
• 闭环反馈： 采用“感知 → 规划 → 执行 → 观察 → 学习/修正”的循环。

可以用一句话概括：生成式 AI 负责产出内容，传统 Agent 负责执行边界内的任务，Agentic AI 系统负责在约束下持续推进复杂目标。

2. Agentic AI 的典型系统架构

目前还没有所有场景都适用的统一设计模式，但大多数系统可以抽象为以下模块：

                +-----------------------+
                |      高层目标/约束      |
                +-----------+-----------+
                            |
                +-----------v-----------+
                |  Planner / Coordinator |
                |  目标分解、调度、仲裁     |
                +-----+-------------+-----+
                      |             |
          +-----------v--+      +---v------------+
          | 专长 Agent A  | ...  | 专长 Agent N    |
          | 检索/编码/评估 |      | 业务动作/审核     |
          +------+--------+      +--------+-------+
                 |                        |
                 +------------+-----------+
                              |
              +---------------v----------------+
              | Memory Store + Tool/API Layer  |
              | 短期/长期记忆、检索、外部系统调用  |
              +---------------+----------------+
                              |
              +---------------v----------------+
              | Perception / Observation / Audit|
              | 环境输入、结果验证、日志、人工介入  |
              +--------------------------------+

2.1 感知模块（Perception）

感知模块接收来自用户、业务系统、文件、传感器或视觉模型的输入，把原始数据转换成当前环境状态。例如，供应链场景需要读取库存、运输位置、天气和订单数据；安全运营场景需要汇总告警、日志和资产信息。

工程上应为感知结果定义稳定的数据结构，并记录时间戳、来源和可信度，避免把无法追溯的自然语言直接当成事实状态。

2.2 规划器与协调器（Planner / Coordinator）

规划器负责把“完成一份市场分析报告”拆成数据采集、竞争对手分析、图表生成、撰写和校验等子任务；协调器负责分配 Agent、管理依赖关系、处理超时和冲突。

简单场景可以采用中心化编排器；多团队或开放网络场景可能采用去中心化协作，但后者更容易出现竞态、重复执行和状态不一致。

2.3 推理引擎与专长 Agent

每个 Agent 通常由 LLM 推理引擎驱动，并配有角色说明、可用工具、输入输出契约和停止条件。常见角色包括：

• Retriever：检索文档、数据库和实时信息；
• Planner：生成或重排任务计划；
• Coder：修改代码、运行测试；
• Evaluator：检查事实、质量和合规性；
• Action Agent：在审批后调用业务 API。

角色拆分的价值在于降低单个提示词的复杂度，同时让权限可以按角色收敛。拆分过细则会增加通信成本和错误传播路径，应以可观测性和业务边界为依据。

2.4 记忆存储（Memory Store）

至少要区分三类状态：

1. 工作记忆： 当前任务的上下文、计划和临时结果。
2. 情景记忆： 过去任务的过程、反馈和失败原因。
3. 语义记忆： 稳定的知识、用户偏好和业务规则。

记忆不是“把所有对话塞进向量库”。每条记忆都应有来源、版本、访问权限、过期时间和删除策略；写入前要做脱敏或分类，读取时要检查租户和角色权限。

2.5 工具与动作层（Tools / Actions）

工具层把模型的推理连接到现实世界，包括检索引擎、数据库、代码执行器、工单系统、支付系统和机器人控制接口。高风险动作应采用最小权限、参数校验、幂等键和人工确认，不能因为模型“认为任务已经完成”就直接提交不可逆操作。

3. 通信协议：让 Agent 能够互操作

论文整理了几种正在发展的协议。它们解决的问题不同，不能简单视为同一个标准：

在企业内部落地时，可以先统一三件事，再决定采用哪种协议：消息格式、身份与权限模型、可观测性字段。至少应包含 trace_id、task_id、parent_task_id、调用者身份、输入输出摘要、超时和重试信息。

4. 一个可执行的闭环

下面是与框架无关的伪代码，展示系统应如何把“自主”限制在可审计的边界内：

def run_goal(goal, constraints, max_steps=20):
    state = observe_environment()
    memory = memory_store.retrieve(goal, state)
    plan = planner.create(goal, constraints, memory)

    for step in range(max_steps):
        action = coordinator.next_action(plan, state, constraints)

        if action.requires_approval:
            approval = human_gate.review(action, state)
            if not approval.accepted:
                return {"status": "stopped", "reason": "human_rejected"}

        result = tool_layer.execute(
            action,
            idempotency_key=f"{goal.id}:{step}"
        )
        audit_log.write(goal, action, result)

        state = observe_environment()
        memory_store.update(goal, state, result)
        evaluation = evaluator.check(result, goal, constraints)

        if evaluation.done:
            return {"status": "completed", "result": result}
        if evaluation.blocked:
            plan = planner.replan(plan, evaluation.feedback, state)

    return {"status": "needs_human_review", "reason": "step_limit"}

这段流程有四个关键控制点：

• 步数上限： 防止 Agent 在错误计划中无限循环。
• 动作审批： 对写入、支付、删除、发布等高风险动作设置人工闸门。
• 幂等执行： 重试不会重复创建订单、工单或付款。
• 结果评估： 每一步都验证是否真的改变了环境，而不是只检查模型生成的文字。

5. 与生成式 AI、传统 Agent 的对比

不要把“多轮对话”“函数调用”或“一个很长的提示词”单独当成 Agentic AI 的充分条件。判断一个系统是否真正具备 Agentic 特征，应该检查它是否能在明确约束下持续管理状态、调用工具、验证结果并推进目标。

6. 适合落地的业务场景

论文讨论了多种应用方向，工程试点可以从低风险、可回滚的流程开始：

6.1 供应链与运营

系统可以持续监控物流、库存和外部事件，预测中断，生成改道方案，并把建议提交给人工审批。自动更新库存或联系承运商前，必须确认数据新鲜度和授权范围。

6.2 网络安全运营

多个 Agent 可以分别负责告警研判、日志检索、影响分析和处置建议；无法确认的异常升级给专家。论文引用的研究报告了特定场景下平均解决时间下降超过 40%，这一数字应理解为案例结果，而不是普适承诺。

6.3 软件工程

Agent 可以从需求拆解、代码生成、测试、静态检查一路协作到发布准备。生产发布、数据库迁移和权限变更仍应由明确的审批和回滚机制控制。

6.4 客户服务与知识工作

检索 Agent、对话 Agent 和升级 Agent 可以共享客户历史，在多渠道处理复杂问题。涉及退款、合同承诺或个人敏感信息时，应把最终决策交给有责任主体的员工。

7. 风险：自主性越强，治理要求越高

Agentic 系统的风险不只来自单次回答错误，还来自错误在多个步骤和多个 Agent 之间传播：

1. 目标错位： 自然语言目标含义不够精确，系统可能优化了错误的指标。
2. 级联错误： 上游检索错误被下游写作、决策和执行不断放大。
3. 权限越界： 能调用工具不等于应该调用工具，角色权限必须与动作风险匹配。
4. 状态污染： 错误或恶意内容写入长期记忆后，会影响后续任务。
5. 协作失控： 多 Agent 可能重复工作、互相覆盖或形成竞态条件。
6. 不可解释与责任不清： 复杂交互使审计困难，组织必须明确谁批准、谁负责、谁有权停止系统。
7. 隐私与能耗： 长期记忆、跨系统数据和持续推理会扩大数据暴露面与计算成本。

建议建立“风险分级 + 控制点”矩阵：低风险动作可自动执行；中风险动作需要规则校验和抽样复核；高风险动作必须人工审批，并保留完整审计记录。系统还需要支持一键暂停、按任务回放、工具调用白名单、预算/步数限制和故障回滚。

8. 企业试点的六步路线

第一步：选择可衡量的目标

优先选择输入稳定、结果可验证、失败可回滚的流程，例如工单分派、内部知识检索或测试报告生成。不要一开始就让 Agent 直接操作支付、生产数据库或人事决策。

第二步：定义状态与成功标准

把目标、约束、输入来源、完成条件、失败条件和人工升级条件写成结构化契约。成功标准必须能由程序或业务人员独立验证。

第三步：先做单 Agent，再引入多 Agent

先验证一个 Agent 的工具调用、记忆和审计闭环，再根据真实瓶颈拆分检索、规划或评估角色。多 Agent 并不会自动带来更高质量，只会增加通信和治理成本。

第四步：收紧工具权限

给每个工具声明输入 schema、超时、重试策略、幂等要求和数据分类；按 Agent 角色发放最小权限，并把写操作与读操作分离。

第五步：建立可观测性与评测集

记录每次规划、工具调用、记忆读写、重规划和人工干预。用一组固定任务评估完成率、事实准确率、平均步数、成本、延迟、升级率和错误恢复率。

第六步：设置发布门禁

上线前进行提示词注入、越权调用、数据泄露、重复执行和故障恢复测试；生产环境使用灰度流量、预算上限和随时可用的停止开关。

9. 结语

Agentic AI 的价值不在于让模型“看起来更像人”，而在于把模型嵌入一个能够管理状态、调用工具、协作分工、验证结果的工程系统。它带来的也不是简单的自动补全，而是业务流程和组织责任的重新设计。

对开发者来说，最实用的判断标准是：目标是否明确，状态是否可追踪，动作是否受控，结果是否可验证，责任是否有人承担。 只有这五点同时成立，Agentic AI 才可能从演示原型走向可靠的生产系统。

参考资料

1. Yogesh K. Dwivedi et al. Agentic AI Systems: What It Is and Isn’t. Global Business and Organizational Excellence, 2026, 45:253–263. DOI: 10.1002/joe.70018.
2. Acharya, D., Kuppan, K., & Divya, B. “Agentic AI: Autonomous Intelligence for Complex Goals—A Comprehensive Survey.” IEEE Access, 2025.
3. Sapkota, R., Roumeliotis, K. I., & Karkee, M. “AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenge.” arXiv:2505.10468, 2025.
4. Shavit, Y. et al. “Practices for Governing Agentic AI Systems.” OpenAI Technical Report, 2023.

发布建议： CSDN 标签可选择 人工智能、AI Agent、大语言模型、多智能体、MCP、软件架构、AI治理。发布时可将摘要作为文章导语，并在文末保留论文 DOI 以便读者查阅原文。