Agentic AI 的范式演进与系统架构拆解

Agentic AI 不是简单地让大语言模型多调用几个工具，而是把模型放进一个闭环系统：它能观察环境、拆解任务、选择动作、调用工具、接收反馈、更新记忆，并在失败时重新规划。

可以先区分两个常见概念：

一句话概括：LLM 更像“大脑”，AI Agent 是“大脑 + 记忆 + 工具 + 反馈”的任务执行系统，Agentic AI 则讨论这种系统如何设计、训练、评估和治理。

从语言模型到 Agent：能力是怎样叠出来的

Agentic AI 的出现并不是突然发生的。它建立在语言建模、神经网络、指令对齐、工具调用和多轮交互这些能力之上。

语言模型到 Agent 的关键变化，不是模型参数变大这么简单，而是交互方式发生了变化。

传统 LLM 的典型模式是：

flowchart LR
    A[用户输入] --> B[LLM 生成回答]
    B --> C[用户阅读结果]

Agent 的典型模式是：

flowchart LR
    A[用户目标] --> B[感知环境]
    B --> C[推理与规划]
    C --> D[调用工具或执行动作]
    D --> E[环境返回反馈]
    E --> F[验证结果]
    F -->|成功| G[输出结果]
    F -->|失败| C
    F --> H[写入记忆]
    H --> C

区别很明显：LLM 的输出通常是一次性的，Agent 的执行过程则会持续观察、行动和修正。只要任务需要跨步骤、跨工具、跨时间完成，就会进入 Agentic AI 的问题空间。

Agent 的核心循环：感知、推理、行动、记忆、验证

一个 Agent 系统通常包含五类组件：

flowchart TB
    U[用户目标 / 外部任务] --> P[感知 Perception]
    P --> R[推理与规划 Reasoning]
    R --> A[行动 Action]
    A --> T[工具 Tools / API / 代码 / 机器人]
    T --> E[环境 Environment]
    E --> O[观测 Observation]
    O --> V[验证器 Validator / 批评家 Critic]
    V -->|通过| OUT[任务结果]
    V -->|失败或不确定| R
    O --> M[记忆 Memory]
    M --> R

可以把 Agent 抽象成一个五元组：

Agent = (πθ, M, T, V, E)

这里的关键点在于：πθ 不是孤立工作的模型，而是一个“策略函数”。它根据目标、记忆、工具结果和环境反馈来决定下一步动作。

一个最小化的 Agent 循环可以写成伪代码：

def agent_loop(goal, policy, memory, tools, validator, max_steps=10):
    observation = None

    for step in range(max_steps):
        context = memory.retrieve(goal=goal, observation=observation)

        action = policy.decide(
            goal=goal,
            context=context,
            observation=observation,
            available_tools=tools.list()
        )

        result = tools.run(action)

        verdict = validator.check(
            goal=goal,
            action=action,
            result=result
        )

        memory.write({
            "step": step,
            "goal": goal,
            "action": action,
            "result": result,
            "verdict": verdict
        })

        if verdict.passed:
            return result

        observation = verdict.feedback

    raise RuntimeError("Agent did not finish within max_steps")

工程上最容易出问题的地方也在这个循环里：模型可能选错工具，工具可能返回噪声，验证器可能过于宽松，记忆可能把错误信息保存下来，环境也可能在执行过程中发生变化。

ReAct：单 Agent 的基础工作流

ReAct 可以理解为 “Reason + Act”，也就是让模型在推理和行动之间交替进行。它不是只输出最终答案，而是把任务拆成一系列“思考—行动—观察”的小循环。

sequenceDiagram
    participant User as 用户
    participant Agent as ReAct Agent
    participant Tool as 工具
    participant Env as 环境

    User->>Agent: 提交任务
    Agent->>Agent: Thought：分析目标和下一步
    Agent->>Tool: Action：调用工具
    Tool->>Env: 查询或执行
    Env-->>Tool: 返回结果
    Tool-->>Agent: Observation：工具反馈
    Agent->>Agent: 根据反馈继续推理
    Agent-->>User: 返回最终结果

一个典型 ReAct 轨迹可能长这样：

Goal: 修复仓库中的一个测试失败问题

Thought: 需要先定位失败测试。
Action: run_tests()
Observation: test_user_service.py::test_create_user 失败。

Thought: 需要查看相关代码。
Action: read_file("services/user_service.py")
Observation: create_user 没有处理重复邮箱。

Thought: 应添加重复邮箱检查，并补充错误返回。
Action: edit_file(...)
Observation: 修改完成。

Thought: 运行测试确认。
Action: run_tests()
Observation: 所有测试通过。

Final: 已修复重复邮箱导致的测试失败。

单 Agent 的优势是结构简单、状态可控、调试成本低。问题也很集中：一旦模型在某个步骤产生幻觉或误解任务，后面的动作会沿着错误方向继续执行。

多 Agent：把复杂任务拆给不同角色

多 Agent 系统会把任务拆成多个角色，例如规划者、执行者、审查者、检索者、代码生成者等。每个 Agent 负责一部分工作，再通过消息协议和共享记忆协作。

flowchart TB
    U[用户目标] --> S[协调者 / Supervisor]

    S --> P[规划 Agent]
    S --> R[检索 Agent]
    S --> C[代码 Agent]
    S --> K[审查 Agent]

    P --> SM[(共享记忆)]
    R --> SM
    C --> SM
    K --> SM

    R --> T1[搜索 / 数据库]
    C --> T2[代码仓库 / 测试工具]
    K --> T3[规则 / 事实核验]

    SM --> S
    S --> OUT[整合结果]

多 Agent 的价值在于分工。复杂任务往往需要不同能力：有人负责制定计划，有人负责查资料，有人负责写代码，有人负责审查风险。如果全部交给一个 Agent，提示词会变得很长，状态也会混乱。

但多 Agent 并不是越多越好。角色越多，通信成本越高，误解也可能级联传播。

多 Agent 系统需要三个基础机制：

1. 通信原语：角色之间如何发消息，消息包含目标、证据、置信度还是动作请求。
2. 冲突仲裁：多个 Agent 给出不同结论时，由谁决定继续、重试或交给人工。
3. 动态分治：任务规模变化时，系统能新增或合并角色，而不是固定一套流程跑到底。

如果没有这些机制，多 Agent 很容易变成多个模型轮流聊天，成本上升，结果却不可控。

三层学习策略：In-Context、IL、RL

Agent 能力的来源不只靠提示词。更完整的训练和优化体系通常分三层：上下文学习、模仿学习、强化学习。

flowchart TB
    A[In-Context Learning 上下文学习] --> B[快速调整提示词、工具说明、策略规则]
    C[IL Imitation Learning 模仿学习] --> D[从专家轨迹学习可执行行为]
    E[RL Reinforcement Learning 强化学习] --> F[通过长期回报优化多步决策]

    B --> G[Agent 系统行为]
    D --> G
    F --> G

上下文学习：把 Prompt 当作软程序

对于很多业务系统，最先落地的往往是上下文学习。它不需要重新训练模型，而是通过提示词、工具 schema、few-shot 示例和策略规则控制 Agent 行为。

一个工具调用模板可以这样设计：

{
  "role": "system",
  "policy": [
    "每次只执行一个外部动作",
    "调用工具前必须说明目标",
    "涉及删除、付款、权限变更时必须请求人工确认",
    "工具失败后最多重试两次"
  ],
  "tools": [
    {
      "name": "search_ticket",
      "description": "按关键词查询工单",
      "input_schema": {
        "keyword": "string",
        "limit": "integer"
      }
    }
  ]
}

这种方式适合快速迭代，但提示词不是强约束。只要任务变长、状态变复杂，系统就需要更强的验证器和外部状态管理。

模仿学习：从专家轨迹学流程

模仿学习的目标是让 Agent 复现专家做事的步骤。比如企业客服 Agent 可以从历史工单中学习：如何判断问题类型、什么时候查询知识库、什么时候升级给人工。

常见做法是行为克隆：把专家轨迹整理成“状态 → 动作”的训练样本，让模型学会在相似状态下选择相似动作。

状态：用户反馈登录失败，错误码为 403
专家动作：查询权限变更记录
工具结果：用户所属角色昨日被移除
专家动作：提交权限恢复审批

行为克隆的风险是分布漂移。训练数据里可能都是“正确前一步”之后的状态，而真实 Agent 一旦走错一步，就会进入专家数据没有覆盖的状态。DAgger（Dataset Aggregation，数据集聚合）会让专家对 Agent 自己产生的状态继续标注，从而扩大训练分布。

强化学习：优化长程任务收益

强化学习更适合处理长程任务，例如自动修复代码、网页连续操作、机器人导航。因为这些任务的成败不取决于单次回答，而取决于一串动作是否最终达到目标。

强化学习要定义奖励：

困难在于奖励通常很稀疏。比如自动编程任务只有在跑完测试后才知道是否成功，中间每一步修改是否正确并不容易判断。这也是验证器、沙箱环境和可回放日志很重要的原因。

六类 Agent 系统：能力边界和风险不同

Agentic AI 覆盖的系统很广，不同类型的 Agent 需要不同的评估方式。

设计 Agent 时不能只问“模型够不够强”，还要问：

• 任务失败的代价是什么？
• 是否允许自动执行真实动作？
• 是否需要人工审批？
• 是否必须给出证据来源？
• 是否需要长期记忆？
• 是否存在实时延迟约束？

医疗、金融、机器人控制这类场景不能依赖“模型看起来回答得不错”，必须引入权限控制、审计日志、事实核验和人工闸门。

工业场景中的关键设计模式

Agent 落地时，任务成功率只是一个指标。更重要的是能不能被监控、能不能回滚、能不能解释、能不能限制风险。

自主编程：不要让 Agent 一次改太多

代码 Agent 最怕“大步修改”。更稳的方式是：

flowchart LR
    A[读取 issue / 测试失败信息] --> B[检索相关文件]
    B --> C[生成最小修改计划]
    C --> D[应用小步 diff]
    D --> E[运行测试]
    E -->|通过| F[输出补丁]
    E -->|失败| G[回滚或缩小修改范围]
    G --> C

小步 diff 的好处很实际：测试失败时更容易定位是哪一步引入的问题，代码审查也更容易接受。

企业工单：权限比能力更重要

企业 Agent 会接触客户数据、内部系统和业务操作。它不应该拥有无限权限，而应该按任务类型拿到最小必要权限。

policy:
  reset_password:
    allowed_roles:
      - support_agent
    require_human_approval: false

  refund_payment:
    allowed_roles:
      - finance_agent
    require_human_approval: true
    max_amount: 500

  delete_customer_data:
    allowed_roles:
      - data_protection_agent
    require_human_approval: true
    require_audit_log: true

策略即代码的价值在于：权限规则不再散落在提示词里，而是能被测试、审计和版本管理。

网页操作：DOM 观测比截图更稳定

让 Agent 操作网页时，可以给它截图，也可以给它 DOM 结构。截图适合多模态理解，但按钮位置、样式变化会影响稳定性；DOM 观测能提供更明确的元素层级、文本和属性。

一个网页操作动作可以记录成结构化日志：

{
  "step": 4,
  "observation": {
    "url": "https://example.com/settings",
    "visible_text": ["Account", "Security", "Change password"]
  },
  "action": {
    "type": "click",
    "target": "button[text='Change password']"
  },
  "result": {
    "status": "success",
    "next_url": "https://example.com/settings/password"
  }
}

这种日志能支持回放和错误分析。只保存自然语言对话，很难定位 Agent 到底点错了哪里。

评估 Agent：不能只看最终答案

传统问答评测通常关注答案对不对。Agent 评测要复杂得多，因为它涉及路径、成本、安全和可恢复性。

一个可审计的 Agent 系统至少要保留这些信息：

{
  "trace_id": "agent-run-20260607-001",
  "goal": "修复登录失败工单",
  "model": "llm-policy-v1",
  "tools_used": ["search_ticket", "query_user_role", "create_approval"],
  "actions": [
    {
      "step": 1,
      "tool": "search_ticket",
      "input": {"keyword": "login 403"},
      "output_hash": "sha256:...",
      "verdict": "passed"
    }
  ],
  "permission_checks": [
    {
      "action": "create_approval",
      "allowed": true,
      "policy": "support_agent.create_approval"
    }
  ],
  "final_status": "handoff_required"
}

没有轨迹日志，Agent 系统很难进入严肃业务场景。因为一旦出错，团队需要知道它为什么做这个动作、用过哪些数据、有没有越权、是否应该由人工接管。

六个关键挑战

Agentic AI 要从演示走向稳定生产，需要解决六类问题。

1. 可验证规划

Agent 生成计划不难，难的是计划能不能被检查。可验证规划要求动作序列有明确前置条件、后置条件和失败处理。

动作：refund_payment(order_id, amount)

前置条件：
- order_id 存在
- amount <= 可退款金额
- 用户身份已验证
- 金额超过阈值时需要人工审批

后置条件：
- 退款记录写入数据库
- 用户收到通知
- 审计日志保存成功

如果计划只是自然语言描述，系统很难自动判断风险。把计划转成结构化动作，才方便验证器检查。

2. 实时可解释

链式思维不适合作为审计材料，因为它可能包含不稳定的推理文本，也可能泄露不该展示的信息。更实用的是“链式证据”：记录每个结论依赖哪些工具结果、规则和数据来源。

3. 持续记忆

长期运行的 Agent 不能把所有历史都塞进上下文。更合理的记忆系统可以分三层：

记忆写入必须谨慎。错误结论一旦进入长期记忆，后续任务可能持续受污染。工程上通常需要给记忆加来源、时间、置信度和过期策略。

4. 多 Agent 协议

多 Agent 需要比“互相发消息”更严格的协议。每条消息最好包含：

{
  "sender": "critic_agent",
  "receiver": "planner_agent",
  "message_type": "risk_report",
  "claim": "退款动作需要人工审批",
  "evidence": ["policy.refund.max_amount", "order.amount"],
  "confidence": 0.94,
  "requested_action": "revise_plan"
}

结构化消息能减少误解，也方便协调者做冲突仲裁。

5. 绿色推理

Agent 往往会多轮调用模型和工具，成本可能迅速上升。绿色推理不是一句口号，而是具体的路由和缓存策略：

6. 治理基础设施

生产级 Agent 需要治理能力，尤其是涉及真实用户、资金、权限和隐私数据的系统。

治理基础设施至少包括：

• 权限即代码：所有高风险动作都有可测试的权限规则。
• 审计日志：每次工具调用、模型决策和人工审批都可追踪。
• 合规基准：针对行业要求设置自动检查。
• 沙箱执行：代码、网页、机器人动作先在隔离环境验证。
• 人工闸门：高风险动作必须由人确认。
• 数据最小化：Agent 只能读取完成任务所需的数据。

一个可落地的 Agent 设计清单

构建 Agent 系统时，可以按这张清单检查：

Agentic AI 的核心不是让模型表现得更像人在聊天，而是让它在真实环境中以可控方式完成任务。模型能力决定上限，系统架构决定稳定性，验证和治理决定能不能进入生产环境。

参考资料

https://arxiv.org/abs/2601.01743
AI Agent Systems: Architectures, Applications, and Evaluation

https://arxiv.org/abs/2601.02749
The Path Ahead for Agentic AI: Challenges and Opportunities