AI Agent（人工智能智能体）不是一个“更会聊天的大模型”，而是一套以大语言模型为推理核心、能够读取环境、规划步骤、调用工具、检查结果并持续迭代的软件系统。

如果只用一句话解释它的运行原理，可以写成：

AI Agent = 大模型推理 + 状态管理 + 工具执行 + 环境反馈 + 停止与安全控制。

从程序结构看，Agent 最核心的部分并不神秘：编排器把任务和当前状态交给模型；模型决定直接回答还是调用工具；程序执行工具并把结果写回状态；模型再根据新证据继续判断。这个循环一直运行到任务完成、需要用户确认，或者触发预算、超时与安全限制。

本文不只解释“Agent 是什么”，还会深入到 API 消息、Tool Calling、ReAct 循环、上下文窗口、RAG、长期记忆、MCP、并发执行、错误恢复、成本优化与可观测性等工程细节。

一、先厘清边界：Agent、聊天机器人和 AI 工作流有什么区别

很多系统接入大模型后都会被称为“智能体”，但真正的 Agent 至少需要具备自主选择下一步行动的能力。

形态	路径由谁决定	是否调用工具	是否形成循环	适合场景
单次大模型调用	程序或用户	可选	否	摘要、分类、改写、信息抽取
聊天机器人	用户对话驱动	可选	多轮对话，但不一定自主执行	问答、咨询、知识助手
AI 工作流	开发者预先定义	通常会	按固定节点运行	审批、抽取、翻译、规则明确的自动化
AI Agent	模型根据状态动态决定	核心能力	是	开放式调研、编程、故障分析、复杂任务执行

Anthropic 在《Building Effective Agents》中把二者区分得很清楚：工作流通过预定义代码路径编排模型和工具；Agent 则由模型动态决定处理过程和工具使用方式。工程上的选择原则也很朴素：固定路径能够解决的问题，优先使用工作流；只有当步骤难以预先枚举时，才值得引入 Agent 的自主性。

二、AI Agent 的整体架构是什么

一个可运行的 Agent 通常由七类组件组成：

1. 任务入口：接收用户目标、约束条件、附件和身份信息。
2. 上下文构建器：组装系统指令、历史消息、知识、工具定义和当前状态。
3. 大模型：理解目标，完成推理、规划和工具选择。
4. 编排器（Agent Runtime）：维护循环、状态、异常、预算和停止条件。
5. 工具层：执行搜索、数据库查询、代码运行、业务 API 调用等确定性操作。
6. 记忆层：保存短期对话、任务检查点、长期知识和用户偏好。
7. 治理层：负责权限、审批、日志、评测、追踪和安全隔离。

图 1：AI Agent 智能体整体运行架构。 大模型负责作出决策，编排器负责执行和约束；模型本身通常不会直接访问数据库、文件系统或业务系统。

这里最容易误解的一点是：工具不是模型执行的，而是宿主程序执行的。 模型输出的通常只是结构化的“调用意图”，例如工具名称和 JSON 参数。编排器验证参数、检查权限后才真正执行工具。这层分离让系统能够设置白名单、审批点、沙箱和审计日志。

三、Agent 的核心：Observe—Think—Act 循环

Agent 常见的运行模式可以抽象成四步：

1. Observe（观察）：读取用户输入、历史状态和工具返回值。
2. Think / Plan（思考与规划）：判断当前任务缺少什么信息，下一步应该做什么。
3. Act（行动）：生成工具调用、向用户提问，或给出最终答案。
4. Update（更新）：把执行结果、错误和检查点写入状态，再进入下一轮。

这种模式与 ReAct（Reasoning and Acting）论文提出的“推理—行动—观察”交替机制高度一致。模型不需要一开始就制定完美计划，而是可以像调试程序一样，每获得一条环境证据就修正下一步。

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

AgentState state = AgentState.start(userGoal);

while (!state.isFinished()) {
    if (state.iterations() >= MAX_ITERATIONS
            || state.elapsedTime() >= TIMEOUT
            || state.tokenCost() >= TOKEN_BUDGET) {
        return stopWithPartialResult(state);
    }

    ModelRequest request = contextBuilder.build(state);
    ModelResponse response = llm.generate(request);
    state.append(response);

    if (response.hasFinalAnswer()) {
        return verifyAndFinish(response, state);
    }

    for (ToolCall call : response.toolCalls()) {
        policyEngine.check(call, state.user());
        ToolResult result = toolExecutor.execute(call);
        state.append(result);
    }
}

真正用于生产的实现还会补充：幂等键、重试策略、熔断、并发控制、人工审批、敏感参数脱敏、结果大小限制、检查点持久化和分布式锁。

四、一次 Tool Calling 在 API 层到底发生了什么

从网络层看，Agent 不是一次 HTTP 请求，而是由多次模型请求和本地工具执行组成的交替过程。

OpenAI 官方文档把工具调用概括为五步：向模型发送可用工具、接收工具调用、在应用侧执行代码、把工具结果再次发送给模型、接收最终回复或下一批工具调用。

图 2：AI Agent 的工具调用时序。 工具调用结果必须与本次调用的 call_id 对应，以便模型区分多次调用和并行结果。

4.1 工具定义为什么使用 JSON Schema

模型在请求中看到的工具定义通常包含名称、用途说明和参数结构：

{
  "type": "function",
  "name": "query_order",
  "description": "根据订单号查询当前用户有权查看的订单状态",
  "strict": true,
  "parameters": {
    "type": "object",
    "properties": {
      "orderNo": {
        "type": "string",
        "description": "业务订单号，例如 SO202607220001"
      }
    },
    "required": ["orderNo"],
    "additionalProperties": false
  }
}

JSON Schema 的作用不是让模型直接执行函数，而是建立模型与确定性程序之间的接口契约。开启严格模式后，模型生成的参数会被约束为指定结构；但业务层仍然必须再次校验订单号格式、登录身份、数据权限和调用频率。

4.2 工具描述本身也是提示工程

工具名称和描述会直接影响模型的选择。模糊的 processData、runTask 很容易导致误用；更好的定义应明确：

• 什么时候使用、什么时候不要使用；
• 输入字段的业务含义、格式和取值范围；
• 是否会产生写入、扣费、发信或删除等副作用；
• 返回值是否完整、是否分页、是否可能延迟；
• 与相似工具之间的边界。

工具返回结果也应“面向模型”设计。与其返回几百 KB 的原始响应，不如返回结构化摘要、关键字段、错误类型和可执行的下一步建议。

4.3 并行调用不是默认答案

当查询彼此独立时，模型可以在一轮中发出多个工具调用，例如同时查询库存、价格和物流。但涉及先后依赖时必须串行，例如先创建审批单，再使用审批单 ID 上传附件。

编排器需要显式维护依赖关系：

可并行：查询客户资料 ─┐
        查询历史订单 ─┼─> 汇总分析
        查询服务记录 ─┘

必须串行：创建工单 -> 获取工单 ID -> 上传附件 -> 通知负责人

五、Agent 为什么“有记忆”：真正被保存的是什么

大模型 API 本身通常不会像人一样永久记住上一轮。Agent 的“记忆”来自宿主系统保存并重新注入的信息。

图 3：AI Agent 的上下文与记忆分层。 上下文窗口是本轮模型真正能看到的工作内存；数据库、向量库和文件只是外部存储，必须经过检索与选择才能进入上下文。

5.1 工作记忆：本轮上下文窗口

一次推理请求通常包含：

[System Instructions]
[Tool Definitions]
[Selected Knowledge / RAG Results]
[Conversation History]
[Task State / Plan / Checkpoint]
[Latest Tool Results]
[Current User Message]

这些内容共同占用上下文窗口。窗口越长并不等于效果一定越好：低相关信息会分散注意力，重复日志会挤占真正有价值的证据。Anthropic 将“为每一步推理选择最有用信息”的工作称为上下文工程，其目标是用尽可能少的高信号 token 支撑下一次正确决策。

5.2 任务记忆：状态和检查点

长任务不应只依赖聊天记录，还要维护结构化状态，例如：

{
  "goal": "分析本月退款率上升原因并生成报告",
  "status": "ANALYZING",
  "completedSteps": ["load_metrics", "segment_by_channel"],
  "pendingSteps": ["inspect_outliers", "draft_report"],
  "artifacts": {
    "dataset": "s3://.../refund-2026-07.parquet",
    "chart": "work/refund-by-channel.png"
  },
  "assumptions": ["退款口径按支付完成日期统计"],
  "unresolvedQuestions": ["渠道 A 在 7 月 15 日是否调整促销规则"]
}

结构化状态比让模型从几万字对话里重新寻找任务进度更稳定，也更容易恢复、审计和并行协作。

5.3 长期记忆：RAG、用户偏好和经验

长期记忆通常分为三类：

• 语义知识：制度、产品说明、代码文档，通过 RAG 检索后注入上下文；
• 情景记录：某次任务做了什么、结果怎样、发生过哪些错误；
• 程序经验：解决某类任务的步骤、模板、Skill 或可执行脚本。

长期记忆的难点不仅是“记住”，还包括去重、过期、冲突、权限和可解释性。把所有历史都向量化并检索，并不能自动得到可靠记忆；系统仍需记录来源、时间、租户、部门、密级和有效期。

六、规划与推理：Agent 如何决定下一步

不同 Agent 的效果差异，很多时候来自“如何组织决策”，而不仅是底层模型不同。

6.1 ReAct：边想边做

ReAct 适合信息需要逐步获取的任务。Agent 每次只决定一个或一小组动作，随后根据真实工具结果调整计划。优点是能及时纠错，缺点是轮次多、成本高，并可能在局部探索中迷路。

6.2 Plan-and-Execute：先规划再执行

系统先生成结构化计划，再由执行器逐项完成：

目标 -> 生成计划 -> 执行步骤 1 -> 检查 -> 执行步骤 2 -> 重规划 -> 完成

这种方式适合步骤较多、依赖较明确的任务。计划不能被当作不可修改的真理；环境证据变化时必须允许重规划。

6.3 Evaluator-Optimizer：生成与评价分离

一个模型或角色生成方案，另一个评价器根据明确标准检查，再反馈修改。它适合代码审查、报告润色、合规检查等可定义质量标准的场景。如果没有明确评价标准，让两个模型互相“讨论”可能只会增加 token，而不会增加正确性。

6.4 状态图：把自主循环装进可控边界

LangGraph 一类框架把 Agent 建模为状态图：State 保存当前快照，Node 执行模型或普通代码，Edge 决定下一个节点。这样可以把部分路径固定、部分路径交给模型动态路由，还能增加检查点、人工介入和故障恢复。

这也是企业级 Agent 常见的架构：不是让模型控制一切，而是把模型放在有限状态机或有向图的关键决策点上。

七、Tool、MCP 和 Skill 分别解决什么问题

三者经常同时出现，但层次不同：

概念	解决的问题	主要内容	典型边界
Tool / Function Calling	模型如何请求执行一个能力	名称、描述、JSON 参数、返回值	单个函数或动作
MCP	Agent 如何标准化连接外部能力和上下文	Host、Client、Server、Tools、Resources、Prompts	连接协议与能力发现
Skill	Agent 如何复用完成某类任务的方法	指令、脚本、模板、示例、资源	任务级方法与经验封装

MCP 采用 Host—Client—Server 架构。Host 是承载 Agent 的应用，一个 Client 通常维护与一个 Server 的会话；Server 暴露工具、资源和提示等能力。MCP 解决的是连接标准化，但不会替 Agent 决定如何管理完整上下文，也不会自动解决权限和业务审批。

Skill 更像可复用的“操作手册 + 脚本包”。Agent 启动时只保留轻量描述，任务匹配后才加载完整内容，这种渐进式披露能够降低无关工具和说明对上下文的占用。

把这些能力真正带进企业，通常需要一个统一的工程载体。例如，云程智能体开发平台将模型、知识库 RAG、Tool、MCP、Skill、Agent 与工作流放在同一套能力体系中管理：开发者既可以让 Agent 动态选择工具，也可以把关键步骤固定在可视化工作流里，并通过版本、权限和调试机制控制能力的发布与调用。它的价值不在于替代前述技术，而是把这些分散组件组织成可复用、可治理的企业 AI 能力。

八、效率与效果如何平衡

Agent 的成本不是一次模型调用的成本，而是整个轨迹的总和：

总成本 ≈ Σ（每轮输入 token + 每轮输出 token）
       + 工具执行成本
       + 检索、存储与沙箱成本
       + 失败重试和评测成本

随着循环进行，历史消息和工具结果不断增长。如果每轮都把全部内容重新交给模型，输入 token 会快速累积。

图 4：AI Agent 的效率、效果与安全控制。 生产系统不能只优化模型准确率，还要同时约束延迟、成本、错误扩散和操作风险。

8.1 模型路由

简单分类、格式转换和摘要可以使用更快、更便宜的模型；复杂规划、关键判断和失败恢复再切换到能力更强的模型。路由依据可以包括任务类型、上下文长度、风险等级、历史失败次数和评价器得分。

8.2 提示缓存

Agent 每轮请求中，系统指令、工具定义和早期历史往往保持不变。提示缓存可以复用完全相同的前缀计算。OpenAI 官方文档强调，缓存命中依赖精确前缀匹配，因此静态内容应放在前面，变化内容放在后面；工具定义、图片和消息顺序也会影响命中。

工程上应注意：不要为了本轮节省少量 token 而频繁改写前部系统提示或重排工具定义，否则可能破坏缓存收益。需要压缩历史时，应在明确的检查点生成新摘要，并把它作为新的稳定前缀。

8.3 按需加载上下文和工具

不要把全部知识、全部文件和几百个工具一次性塞入上下文。更好的策略是：

• 先注入文件路径、索引和简短描述；
• 需要时再通过搜索、RAG 或文件工具加载正文；
• 根据任务类型只开放必要工具子集；
• 对大结果先在代码侧过滤、聚合和压缩；
• 把中间产物保存为文件或结构化状态，而不是反复复制进消息。

8.4 明确预算和停止条件

至少设置以下安全阀：

• 最大模型调用次数；
• 最大输入/输出 token；
• 最大墙钟时间；
• 单工具超时和重试次数；
• 最大并发数；
• 最大费用或资源配额；
• 连续无进展次数；
• 必须人工确认的高风险动作。

九、可靠性与安全：为什么 Agent 比聊天机器人更难上线

聊天机器人的错误通常是一段错误文字；Agent 的错误可能变成一次错误写入、错误邮件、错误付款或错误删除。因此生产级系统要限制“爆炸半径”。

9.1 权限控制必须落在工具执行层

不能只在系统提示里写“不要访问无权数据”。每次工具调用都要由服务端根据用户、租户、角色、数据范围和操作类型重新鉴权。模型生成的参数永远视为不可信输入。

9.2 有副作用的操作要分级

可以把工具分为：

• 只读工具：搜索、查询、预览；
• 可逆写入：创建草稿、添加标签、生成待审批记录；
• 高风险写入：发送消息、执行付款、修改权限、删除数据。

高风险动作应采用“模型提出—程序校验—用户确认—服务端执行”的四段式流程，并提供幂等键、事务或补偿操作。

9.3 防御提示注入

网页、邮件、文档和工具返回内容都可能包含针对 Agent 的恶意指令。系统必须区分“数据”和“指令”，限制不可信内容影响高权限工具，并避免同时赋予 Agent 广泛私有数据访问和任意外发能力。

9.4 用环境结果而不是模型自信度验收

代码 Agent 要跑测试，数据 Agent 要核对统计口径，流程 Agent 要读取业务系统回执。模型说“已经完成”不等于任务真的完成。验收应尽量依赖数据库状态、文件哈希、测试结果、API 回执等可验证证据。

十、可观测性：如何知道 Agent 为什么成功或失败

至少记录一条完整轨迹（trace）：

run_id
  ├─ 用户目标与约束
  ├─ 每轮模型、耗时、token 和缓存命中
  ├─ 工具名称、参数摘要、权限决策和返回状态
  ├─ 状态变更、计划变更和检查点
  ├─ 重试、异常与人工确认
  └─ 最终结果、验收证据和评价得分

日志既要足够完整以便重放和定位问题，又不能泄露提示词中的密钥、个人信息和业务敏感数据。常见做法是保存结构化摘要，对原始请求做分级留存和脱敏，并建立 run_id -> model_call_id -> tool_call_id 的关联关系。

Agent 评测也不能只看最终文字。更完整的指标包括：任务成功率、工具选择正确率、参数正确率、平均步骤数、人工介入率、恢复成功率、P95 延迟、单任务成本和高风险误操作率。

十一、一个企业订单分析 Agent 的完整运行示例

用户提出：“分析华东地区本月订单退款率突然上升的原因，生成一份报告，但不要修改任何业务数据。”

系统可以按下面的轨迹运行：

1. 编排器读取用户身份和“只读”约束，只开放订单查询、指标计算、制度检索和文件生成工具。
2. 模型把任务拆成口径确认、趋势定位、渠道分组、异常日期分析和报告生成。
3. Agent 先检索指标口径，确认退款率的分子、分母和时间字段。
4. 并行查询各省、渠道、品类和日期维度的聚合数据，不直接读取不必要的客户明细。
5. 发现某渠道在 7 月中旬异常后，继续检索促销规则和系统变更记录。
6. 编排器将大结果保存在数据文件中，只把统计摘要和异常点注入模型上下文。
7. 模型形成原因假设，调用代码工具完成交叉验证并生成图表。
8. 评价节点检查报告是否包含数据口径、证据、未知项和建议，避免把相关性写成因果性。
9. 文件生成工具输出报告；系统保存查询参数、图表哈希和数据时间戳作为验收证据。

这个例子体现了 Agent 的真正价值：不是一次回答问题，而是在受控权限内动态决定调查路径，用工具取得事实，再把多个中间结果组织成可以交付的成果。

十二、什么时候不应该使用 Agent

以下情况通常更适合普通程序或 AI 工作流：

• 步骤完全固定，输入输出结构稳定；
• 必须做到强确定性，错误容忍度极低；
• 单次模型调用加 RAG 已能满足效果；
• 没有客观的完成标准或环境反馈；
• 工具权限过大，但又无法增加审批和隔离；
• 任务价值不足以覆盖多轮推理的延迟与费用。

一条实用的升级路线是：

规则程序 -> 单次 LLM -> LLM + RAG/Tool -> 固定 AI 工作流
        -> 单 Agent -> 受控多 Agent

每增加一层复杂度，都应通过评测证明它确实提高了任务成功率，而不是仅仅让系统显得更“智能”。

十三、如果只记住五句话

1. AI Agent 是大模型在环境反馈中持续调用工具的受控循环。
2. 大模型负责决策，宿主程序负责执行、鉴权、状态和安全。
3. 上下文窗口不是数据库，记忆必须经过保存、检索、压缩和权限过滤。
4. 效率优化的核心是减少无效轮次、按需加载上下文、复用稳定前缀并设置预算。
5. 能用确定性工作流解决的问题，不必升级为 Agent；可靠性比架构复杂度更重要。

对企业级 AI 应用而言，真正可用的智能体平台不只是提供一个聊天页面，而是要同时覆盖模型接入、Agent 编排、工作流、RAG、Tool/MCP/Skill、权限审批、沙箱执行、链路追踪、评测和成本治理。以云程的产品思路为例，重点不是让 Agent 获得无限权限，而是让模型、知识、工具和流程在统一边界内组合、发布和追踪。只有这些工程能力共同存在，Agent 的“自主性”才可能从演示效果变成可控的生产能力。