1,377
社区成员
发帖
与我相关
我的任务
分享Agentic AI 系统：从“会回答”到“能完成任务”的架构、协议与治理
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）
至少要区分三类状态：
- 工作记忆： 当前任务的上下文、计划和临时结果。
- 情景记忆： 过去任务的过程、反馈和失败原因。
- 语义记忆： 稳定的知识、用户偏好和业务规则。
记忆不是“把所有对话塞进向量库”。每条记忆都应有来源、版本、访问权限、过期时间和删除策略；写入前要做脱敏或分类，读取时要检查租户和角色权限。
2.5 工具与动作层（Tools / Actions）
工具层把模型的推理连接到现实世界，包括检索引擎、数据库、代码执行器、工单系统、支付系统和机器人控制接口。高风险动作应采用最小权限、参数校验、幂等键和人工确认，不能因为模型“认为任务已经完成”就直接提交不可逆操作。
3. 通信协议：让 Agent 能够互操作
论文整理了几种正在发展的协议。它们解决的问题不同，不能简单视为同一个标准：
| 协议 | 主要定位 | 典型用途 | 当前注意点 |
|---|---|---|---|
| MCP | LLM 与工具或资源的结构化交互 | 调用搜索、数据库和企业工具 | 需要补足发现、权限和安全治理 |
| ACP | 基于 REST 的 Agent 消息协作 | 模块化 Agent 之间传递任务和结果 | 状态管理能力相对有限 |
| A2A | Agent 对 Agent 的异步通信与任务委派 | 能力交换、跨 Agent 协作 | 生态可能形成协议孤岛 |
| ANP | 面向开放网络的点对点发现 | 基于身份的 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 的对比
| 维度 | 生成式 AI | 传统 AI Agent | Agentic AI 系统 |
|---|---|---|---|
| 核心产物 | 文本、图片、代码等内容 | 单个边界任务的结果 | 完成多步骤业务工作流 |
| 记忆 | 依赖当前上下文窗口 | 短期上下文或可选记忆 | 持久化情景记忆与语义记忆 |
| 控制方式 | 用户逐次提示 | 预定义流程和工具 | 目标分解、调度、反馈和重规划 |
| 协作方式 | 单模型交互 | 单 Agent 为主 | 多 Agent 分工与协商 |
| 外部行动 | 通常不直接行动 | 调用少量工具 | 连接 API、数据库和执行系统 |
| 适用任务 | 写作、总结、代码补全 | 分类、搜索、客服 | 供应链编排、安全响应、研发流程 |
| 主要风险 | 幻觉、偏见、版权和隐私 | 工具误用、流程边界错误 | 目标偏移、级联错误、涌现行为和责任不清 |
不要把“多轮对话”“函数调用”或“一个很长的提示词”单独当成 Agentic AI 的充分条件。判断一个系统是否真正具备 Agentic 特征，应该检查它是否能在明确约束下持续管理状态、调用工具、验证结果并推进目标。
6. 适合落地的业务场景
论文讨论了多种应用方向，工程试点可以从低风险、可回滚的流程开始：
6.1 供应链与运营
系统可以持续监控物流、库存和外部事件，预测中断，生成改道方案，并把建议提交给人工审批。自动更新库存或联系承运商前，必须确认数据新鲜度和授权范围。
6.2 网络安全运营
多个 Agent 可以分别负责告警研判、日志检索、影响分析和处置建议；无法确认的异常升级给专家。论文引用的研究报告了特定场景下平均解决时间下降超过 40%，这一数字应理解为案例结果，而不是普适承诺。
6.3 软件工程
Agent 可以从需求拆解、代码生成、测试、静态检查一路协作到发布准备。生产发布、数据库迁移和权限变更仍应由明确的审批和回滚机制控制。
6.4 客户服务与知识工作
检索 Agent、对话 Agent 和升级 Agent 可以共享客户历史，在多渠道处理复杂问题。涉及退款、合同承诺或个人敏感信息时，应把最终决策交给有责任主体的员工。
7. 风险：自主性越强，治理要求越高
Agentic 系统的风险不只来自单次回答错误，还来自错误在多个步骤和多个 Agent 之间传播：
- 目标错位： 自然语言目标含义不够精确，系统可能优化了错误的指标。
- 级联错误： 上游检索错误被下游写作、决策和执行不断放大。
- 权限越界： 能调用工具不等于应该调用工具，角色权限必须与动作风险匹配。
- 状态污染： 错误或恶意内容写入长期记忆后，会影响后续任务。
- 协作失控： 多 Agent 可能重复工作、互相覆盖或形成竞态条件。
- 不可解释与责任不清： 复杂交互使审计困难，组织必须明确谁批准、谁负责、谁有权停止系统。
- 隐私与能耗： 长期记忆、跨系统数据和持续推理会扩大数据暴露面与计算成本。
建议建立“风险分级 + 控制点”矩阵：低风险动作可自动执行；中风险动作需要规则校验和抽样复核；高风险动作必须人工审批，并保留完整审计记录。系统还需要支持一键暂停、按任务回放、工具调用白名单、预算/步数限制和故障回滚。
8. 企业试点的六步路线
第一步：选择可衡量的目标
优先选择输入稳定、结果可验证、失败可回滚的流程，例如工单分派、内部知识检索或测试报告生成。不要一开始就让 Agent 直接操作支付、生产数据库或人事决策。
第二步：定义状态与成功标准
把目标、约束、输入来源、完成条件、失败条件和人工升级条件写成结构化契约。成功标准必须能由程序或业务人员独立验证。
第三步：先做单 Agent，再引入多 Agent
先验证一个 Agent 的工具调用、记忆和审计闭环，再根据真实瓶颈拆分检索、规划或评估角色。多 Agent 并不会自动带来更高质量，只会增加通信和治理成本。
第四步：收紧工具权限
给每个工具声明输入 schema、超时、重试策略、幂等要求和数据分类；按 Agent 角色发放最小权限，并把写操作与读操作分离。
第五步：建立可观测性与评测集
记录每次规划、工具调用、记忆读写、重规划和人工干预。用一组固定任务评估完成率、事实准确率、平均步数、成本、延迟、升级率和错误恢复率。
第六步：设置发布门禁
上线前进行提示词注入、越权调用、数据泄露、重复执行和故障恢复测试；生产环境使用灰度流量、预算上限和随时可用的停止开关。
9. 结语
Agentic AI 的价值不在于让模型“看起来更像人”，而在于把模型嵌入一个能够管理状态、调用工具、协作分工、验证结果的工程系统。它带来的也不是简单的自动补全，而是业务流程和组织责任的重新设计。
对开发者来说，最实用的判断标准是：目标是否明确，状态是否可追踪，动作是否受控，结果是否可验证，责任是否有人承担。 只有这五点同时成立，Agentic AI 才可能从演示原型走向可靠的生产系统。
参考资料
- 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.
- Acharya, D., Kuppan, K., & Divya, B. “Agentic AI: Autonomous Intelligence for Complex Goals—A Comprehensive Survey.” IEEE Access, 2025.
- Sapkota, R., Roumeliotis, K. I., & Karkee, M. “AI Agents vs. Agentic AI: A Conceptual Taxonomy, Applications and Challenge.” arXiv:2505.10468, 2025.
- Shavit, Y. et al. “Practices for Governing Agentic AI Systems.” OpenAI Technical Report, 2023.
发布建议： CSDN 标签可选择 人工智能、AI Agent、大语言模型、多智能体、MCP、软件架构、AI治理。发布时可将摘要作为文章导语，并在文末保留论文 DOI 以便读者查阅原文。
...全文
请发表友善的回复…
发表回复
innnuhs 08-28 13:29
- 打赏
- 举报
不错
