大模型 Agentic 推理框架：单智能体、工具调用与多智能体协作

大语言模型（Large Language Model，LLM）本身擅长生成文本，但真实任务往往不只是“回答一句话”。用户可能希望它查资料、写代码、运行测试、分析医学病例、调用数据库、协调多个角色完成软件开发，甚至在模拟社会里让多个虚拟个体持续互动。

这类系统的核心不再是“训练一个更大的模型”，而是“如何把 LLM 组织成一个会行动的系统”。这就是 Agentic 推理框架要解决的问题。

一个典型的 AI Agent 不只是调用一次模型，而是围绕目标反复执行：

flowchart LR
    A[任务目标] --> B[理解上下文]
    B --> C[制定计划]
    C --> D[执行动作]
    D --> E{是否需要外部信息或工具}
    E -- 是 --> F[调用工具或环境]
    F --> G[获得观察结果]
    E -- 否 --> H[内部推理]
    G --> I[反思与修正]
    H --> I
    I --> J{是否完成任务}
    J -- 否 --> C
    J -- 是 --> K[输出结果]

这个循环让 LLM 从“生成器”变成“执行器”：它可以把复杂问题拆成步骤，根据中间结果调整策略，并在必要时借助外部工具补齐自身能力。

Agentic 推理到底是什么

Agentic 推理可以理解为一种基于 LLM 的闭环决策过程。它有几个关键元素：

如果把它写成伪代码，核心循环大致是这样：

def run_agent(task, llm, tools, memory, max_steps=10):
    state = {
        "task": task,
        "history": [],
        "memory": memory.load(task),
    }

    for step in range(max_steps):
        action = llm.decide_next_action(state)

        if action.type == "tool_call":
            observation = tools[action.name](**action.arguments)
        elif action.type == "reasoning":
            observation = llm.reason(state, action.prompt)
        elif action.type == "reflect":
            observation = llm.reflect(state)
        else:
            observation = None

        state["history"].append({
            "step": step,
            "action": action,
            "observation": observation,
        })

        if llm.is_finished(state):
            return llm.final_answer(state)

    return llm.final_answer_with_uncertainty(state)

这里最重要的变化是：LLM 不再一次性给答案，而是在“决策—行动—观察—修正”的循环中逐步逼近目标。

三层能力：单智能体、工具增强、多智能体

Agentic 框架可以按照能力递进分成三层：

flowchart TB
    A[单智能体<br/>让一个 LLM 自己想得更清楚] --> B[工具增强智能体<br/>让 LLM 会调用外部资源]
    B --> C[多智能体系统<br/>让多个 Agent 分工协作或互相博弈]

    A --> A1[Prompt 工程]
    A --> A2[链式思考]
    A --> A3[自我反思与迭代]

    B --> B1[工具接入]
    B --> B2[工具选择]
    B --> B3[工具执行与结果校验]

    C --> C1[中心化组织]
    C --> C2[分布式组织]
    C --> C3[层级式组织]

三层不是互斥关系。很多真实系统会同时使用它们：一个主 Agent 负责规划，多个子 Agent 负责不同任务，每个子 Agent 又能调用搜索、代码执行、数据库、检索增强生成（Retrieval-Augmented Generation，RAG）等工具。

单智能体：把一个 LLM 组织得更会思考

单智能体框架只依赖一个主要 LLM，但会通过 Prompt 设计、推理链、反思机制，让模型处理更复杂的任务。

Prompt 工程的四个维度

一个有效的 Agent Prompt 通常不只是“请回答问题”，而是包含角色、环境、任务和示例四类信息。

一个代码修复 Agent 的系统提示词可以写成：

你是一个 Python 项目维护 Agent。

目标：
- 定位测试失败原因
- 修改最少的代码
- 保持原有 API 行为不变
- 修复后运行相关测试

可用动作：
- read_file(path)
- write_file(path, content)
- run_tests(command)

输出要求：
- 说明失败原因
- 列出修改文件
- 给出验证命令和测试结果

Prompt 的价值不在于“写得长”，而在于把边界说清楚。边界越清楚，Agent 越不容易在循环中偏离目标。

链式思考、任务分解与计划

复杂任务通常不能一步完成。单智能体会先把任务拆开，再逐步处理。

flowchart LR
    A[复杂任务] --> B[拆解子任务]
    B --> C[确定执行顺序]
    C --> D[逐步生成中间结果]
    D --> E[汇总答案]

例如让 Agent 分析一个开源项目的性能瓶颈，它可以拆成：

1. 读取项目结构；
2. 找到入口函数和核心调用链；
3. 搜索可能的高复杂度代码；
4. 运行基准测试；
5. 对比修改前后的指标；
6. 给出优化建议。

这种方式比一次性回答更稳定，因为每一步都有局部目标和中间产物。

自我反思：让 Agent 从失败中修正

单智能体常见的自我提升机制有三类：

Self-Refine 的流程很直观：

flowchart LR
    A[生成初稿] --> B[评估缺陷]
    B --> C[给出修改建议]
    C --> D[重写结果]
    D --> E{是否满足标准}
    E -- 否 --> B
    E -- 是 --> F[输出最终结果]

这类方法的关键在于评估标准。如果标准含糊，反思就会变成“看起来更好”的文本润色，而不是可验证的改进。比如代码任务里，“通过测试”比“代码质量更高”更适合作为终止条件。

工具增强智能体：让 LLM 长出手脚

LLM 的知识来自训练语料和上下文窗口，天然不擅长处理实时数据、精确计算、数据库查询、代码执行和专业软件操作。工具增强智能体会把这些能力外包给外部工具。

工具增强的基本链路是：

flowchart LR
    A[任务] --> B[识别需要外部能力]
    B --> C[选择工具]
    C --> D[构造调用参数]
    D --> E[执行工具]
    E --> F[解析返回结果]
    F --> G[继续推理或再次调用]

工具接入：API、插件和中间件

工具可以分成三类：

工具描述要清楚到模型能正确选择和调用。一个简单的工具定义可以这样写：

{
  "name": "search_papers",
  "description": "根据关键词检索论文，返回标题、摘要、年份和链接",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "检索关键词，例如 'LLM agent tool use'"
      },
      "max_results": {
        "type": "integer",
        "description": "返回结果数量，最多 10 条"
      }
    },
    "required": ["query"]
  }
}

如果工具说明只写“搜索论文”，模型很容易传错参数，或者在不需要搜索时也调用搜索。工具定义越规范，Agent 的执行越可控。

工具选择：零样本、规则和学习型策略

Agent 选择工具通常有三种方法：

工具数量少时，直接让模型选择就够了；工具数量多、调用代价高或权限敏感时，需要引入规则、路由器或专门的规划模块。

工具使用：顺序调用、并行调用和迭代调用

工具调用不只有一种形态：

flowchart TB
    A[工具调用策略]

    A --> B[顺序调用]
    B --> B1[搜索资料]
    B1 --> B2[提取信息]
    B2 --> B3[生成报告]

    A --> C[并行调用]
    C --> C1[查数据库]
    C --> C2[查搜索引擎]
    C --> C3[跑本地脚本]

    A --> D[迭代调用]
    D --> D1[调用工具]
    D1 --> D2[检查结果]
    D2 --> D3{是否足够}
    D3 -- 否 --> D1
    D3 -- 是 --> D4[输出]

顺序调用适合强依赖任务，比如“先检索论文，再总结”；并行调用适合彼此独立的任务，比如同时查询多个数据源；迭代调用适合需要不断修正的任务，比如代码修复和科学实验设计。

像 ChemCrow 这类化学 Agent，会把多个专业工具串成一条工作流，用于分子检索、性质预测、反应规划和实验建议。像 LLM-Compiler 这类调度框架，则会分析工具之间的依赖关系，把没有依赖的调用并行执行，从而减少整体延迟。

多智能体：让多个 Agent 分工、辩论和协商

单个 Agent 的能力有上限。任务很复杂时，可以让多个 Agent 承担不同角色，例如产品经理、架构师、开发者、测试工程师、安全审查员。多智能体系统关注两个问题：

1. 这些 Agent 如何组织；
2. 它们如何交互。

三种组织结构

中心化结构像一个项目经理带团队，适合软件项目管理、任务编排和严格流程控制。分布式结构像多人辩论，适合需要不同视角互相纠错的判断任务。层级式结构更像企业组织，可以把复杂任务分给不同层级处理。

flowchart TB
    subgraph Centralized[中心化]
        M1[Manager] --> A1[Agent A]
        M1 --> B1[Agent B]
        M1 --> C1[Agent C]
    end

    subgraph Decentralized[分布式]
        A2[Agent A] <--> B2[Agent B]
        B2 <--> C2[Agent C]
        C2 <--> A2
    end

    subgraph Hierarchical[层级式]
        L1[总控 Agent] --> L2A[子团队 Agent]
        L1 --> L2B[子团队 Agent]
        L2A --> L3A[执行 Agent]
        L2A --> L3B[执行 Agent]
        L2B --> L3C[执行 Agent]
    end

三种交互协议

多智能体不是“Agent 越多越好”。如果任务本身很简单，引入多个 Agent 只会增加成本和延迟。多智能体适合的问题通常具备以下特征：

• 任务可拆成多个角色或阶段；
• 不同子任务需要不同知识；
• 结果需要审查、辩论或交叉验证；
• 单个 Agent 容易遗漏关键约束。

四类典型应用场景

Agentic 框架的应用可以分成科学发现、医疗、软件工程、社会经济模拟四大类。它们的共同点是：任务链条长、工具依赖强、单次问答难以完成。

科学发现：把假设、工具和验证串起来

科学任务通常包含假设生成、数据查询、实验设计、模拟验证和结果解释。Agentic 框架适合把这些步骤组织成闭环。

生化场景尤其适合工具增强 Agent。LLM 本身不能可靠计算分子性质，但可以规划“该调用哪个工具、用什么输入、如何解释结果”。例如一个分子设计 Agent 可以这样工作：

flowchart LR
    A[目标性质] --> B[生成候选分子]
    B --> C[调用性质预测工具]
    C --> D[评估药物相似性]
    D --> E[检查合成可及性]
    E --> F{是否达标}
    F -- 否 --> B
    F -- 是 --> G[输出候选分子与理由]

常见评估指标包括：

常见数据集和资源包括 MoleculeNet、CrossDocked、CheMBL 等。

医疗：诊断、临床管理和医院仿真

医疗 Agent 的核心不是替代医生，而是辅助完成信息整理、候选诊断生成、用药建议检查和临床流程模拟。这个场景对安全性要求极高，输出必须有证据链和不确定性说明。

多智能体在医疗诊断中很常见。不同 Agent 可以模拟不同科室角色，给出各自判断，再由协调者整合。

sequenceDiagram
    participant U as 病例输入
    participant G as 全科 Agent
    participant C as 心内科 Agent
    participant N as 神经科 Agent
    participant M as 管理 Agent

    U->>G: 症状、检查、病史
    U->>C: 症状、检查、病史
    U->>N: 症状、检查、病史
    G-->>M: 初步诊断与证据
    C-->>M: 专科判断与风险
    N-->>M: 鉴别诊断
    M-->>U: 汇总建议、证据、不确定性

常见评测资源包括 MedQA、PubMedQA、MIMIC-IV、MVME 等。指标不能只看准确率，还要看安全率、人类专家一致性、证据引用质量和拒答能力。

软件工程：从代码生成到全生命周期开发

软件工程是 Agentic 框架最容易落地的方向之一，因为它天然具备明确反馈：代码能不能编译，测试能不能通过，补丁有没有引入回归。

一个程序修复 Agent 的闭环可以画成：

flowchart LR
    A[测试失败] --> B[读取报错日志]
    B --> C[定位相关文件]
    C --> D[生成补丁]
    D --> E[运行测试]
    E --> F{测试通过}
    F -- 否 --> G[分析失败原因]
    G --> C
    F -- 是 --> H[输出补丁和说明]

MetaGPT、ChatDev 这类系统会把软件开发拆成多个角色：产品经理写需求，架构师设计模块，工程师写代码，测试工程师生成用例。这样做的优势是流程清晰，但也容易产生冗余沟通。真实落地时，需要控制角色数量，并让每个角色的输出能被自动验证。

社会经济模拟：观察群体行为和市场互动

社会经济模拟关注多个 Agent 在环境中的长期互动。每个 Agent 可以有身份、记忆、偏好和目标，从而产生群体行为。

这类系统的难点在于校准。Agent 生成的行为看起来像人，并不等于符合真实社会规律。评估时需要对比真实数据分布、行为统计特征和长期演化趋势，不能只凭单个案例判断。

如何评测 Agentic 框架

Agentic 系统不能只用普通问答准确率评估。因为它有过程、有工具调用、有多轮状态，还可能涉及安全和成本。

不同场景的评测重点不一样：

一个可靠的评测集最好同时包含最终答案和过程日志。只看最终结果，很难知道 Agent 是真的推理正确，还是碰巧生成了正确答案。

落地时最容易踩的坑

工具描述不清，Agent 会乱调用

工具名、参数、返回格式、失败情况都要明确。否则模型可能把搜索工具当数据库用，把计算器当推理器用，或者传入不存在的参数。

好的工具描述应该包含：

• 工具能做什么；
• 不能做什么；
• 参数类型和约束；
• 返回结果格式；
• 调用失败时的错误信息；
• 是否需要权限或成本。

反思循环没有终止条件

自我反思很有用，但没有终止条件会导致 Agent 无限修改。常见控制方式包括：

stop_conditions = [
    "测试全部通过",
    "答案达到评分阈值",
    "连续两轮没有改进",
    "达到最大迭代次数",
    "工具调用预算用完",
]

反思不是目的，完成任务才是目的。

多智能体容易制造“假共识”

多个 Agent 讨论后给出一致答案，并不代表答案一定正确。如果它们使用相同模型、相同提示词、相同上下文，就可能犯同样的错误。要提高多智能体的互补性，可以让它们拥有不同角色、不同信息源、不同评估标准，必要时引入外部验证工具。

工具调用会放大安全风险

Agent 能调用工具后，风险从“说错话”升级为“做错事”。例如错误删除文件、泄露数据库字段、执行危险命令、把恶意网页内容写入系统提示。工程上需要加入权限边界：

flowchart LR
    A[Agent 决策] --> B{权限检查}
    B -- 允许 --> C[执行工具]
    B -- 拒绝 --> D[返回拒绝原因]
    C --> E[记录日志]
    E --> F[结果返回 Agent]

高风险工具应采用人工确认、沙箱执行、只读模式或白名单参数。

成本和延迟可能被低估

Agentic 框架通常会多轮调用模型，还可能调用多个工具或多个 Agent。一个看似简单的任务，背后可能产生几十次 LLM 请求。落地前需要记录：

• 每个任务平均调用多少次模型；
• 每次调用输入输出 Token 数；
• 工具调用耗时；
• 并行策略是否真的降低延迟；
• 失败重试造成的额外成本。

一个可执行的 Agentic 系统设计模板

设计一个 Agentic 应用时，可以从五个模块开始：

flowchart TB
    A[用户任务] --> B[规划器 Planner]
    B --> C[执行器 Executor]
    C --> D[工具层 Tools]
    D --> C
    C --> E[验证器 Verifier]
    E --> F{是否通过}
    F -- 否 --> B
    F -- 是 --> G[最终输出]
    H[记忆 Memory] <--> B
    H <--> C

各模块职责如下：

最小实现不需要一开始就做复杂多智能体。可以按照这个顺序增加能力：

1. 先做单 Agent，保证基础任务能跑通；
2. 加入工具调用，处理实时信息和外部执行；
3. 加入验证器，用测试、规则或评分模型检查结果；
4. 对复杂任务引入多角色协作；
5. 增加日志、权限、成本控制和安全策略。

Agentic 框架的关键不是让 LLM “看起来像人在工作”，而是把任务拆解、工具执行、反馈修正和结果验证组织成一个可控闭环。只有闭环可观察、可评测、可回滚，Agent 才能从演示走向稳定应用。