直接答案：AI Agent（人工智能智能体）不是一个更会聊天的模型，而是一套让模型在受控运行时中围绕目标读取当前状态、提出下一步、选择工具、接收执行结果并决定继续或停止的软件系统。模型负责生成候选决策；应用负责参数校验、身份授权、工具执行、状态保存、审批、限额和审计。一次模型回答、一次函数调用或一条固定自动化流程，都不应自动被称为 Agent。
OpenAI 的智能体实践指南把 Agent 概括为能够代表用户独立完成任务的系统，并把模型、工具和指令列为基础组件；Anthropic 在Building effective agents中进一步区分了工作流与智能体：工作流沿预先写好的代码路径运行，智能体则由模型根据过程状态动态决定下一步。两种定义并不冲突，它们共同说明“模型参与控制多步执行”比营销名称更重要。
AI Agent、智能体和 Agentic AI 分别指什么？
中文语境里，“AI Agent”“智能体”“代理式 AI”经常混用。本文把 AI Agent 用作一个可运行软件系统：它接受目标，拥有一组受限工具，在多轮中根据观察结果调整动作。Agentic AI 更适合描述系统呈现出的代理式特征或一类架构，并不保证每个产品都拥有相同自主程度。判断一个具体系统时，应查看它实际控制什么流程，而不是只看名称中是否出现 Agent。
| 名词 | 本文采用的含义 | 不能由名称推出 |
|---|---|---|
| LLM | 根据上下文生成输出的模型 | 拥有外部权限或会执行代码 |
| AI Agent | 模型参与多步决策并通过受控工具影响环境的系统 | 完全自主、可靠或无需人工 |
| Agentic workflow | 包含模型决策或代理式步骤的工作流 | 每一步都由模型自主规划 |
| 多智能体 | 多个角色或执行单元协作的系统 | 一定优于单 Agent 或固定流程 |
Google Cloud 的AI agents 核心概念把模型、接地信息、工具、数据架构、编排和运行时拆开说明。这种拆分很重要：模型能力只是系统的一层，可靠性还取决于数据是否当前、工具是否清楚、权限是否足够小、运行状态是否持久、异常是否能恢复。
什么条件下才算一个 AI Agent？
工程上没有唯一且永久不变的行业定义，但可以用可观察条件代替概念争论。一个系统至少应当有目标、运行状态、候选动作、环境反馈和终止条件；模型要实质参与“下一步做什么”的决策。长期记忆、反思、多模态、多 Agent、向量数据库和某个开发框架都可能有用，却不是所有 Agent 的必备条件。
| 检查项 | 最低可观察证据 | 缺失时更像什么 |
|---|---|---|
| 目标 | 有完成、失败与转人工条件 | 开放式聊天 |
| 状态 | 知道当前步骤、已有结果和剩余限制 | 彼此无关的多次问答 |
| 选择 | 模型会根据当前状态选择回答、工具或停止 | 固定脚本 |
| 行动 | 受控读取或改变外部系统 | 纯文本生成 |
| 反馈 | 工具真实返回会影响后续决定 | 预先写好的演示 |
ReAct 原论文将推理与特定任务动作交替，让系统从外部知识库或环境取得信息，再更新后续步骤。它是理解 Agent 循环的重要研究路线，但ReAct 论文中的实验结果属于其任务、模型和设置，不能外推为所有生产 Agent 的成功率保证，也不意味着应用必须公开或保存模型的私有推理过程。
Agent 与聊天机器人、工作流、RPA 有什么区别？
最容易犯的错误，是把所有接入大模型的程序都升级为“智能体”。如果用户提问后只得到一次回答，它仍是对话应用；如果步骤和分支完全由程序写死，它更接近固定工作流；如果按界面坐标或规则重复操作，它更接近 RPA。Agent 的独立价值出现在步骤难以提前穷举、环境反馈会改变路线，而且每一步仍能被验证和约束的任务中。
| 形态 | 谁决定下一步 | 适合任务 | 主要失败 |
|---|---|---|---|
| 聊天机器人 | 通常由用户发起下一轮 | 解释、摘要、草拟、问答 | 回答错误但通常无外部副作用 |
| 固定工作流 | 代码中的顺序和分支 | 规则稳定、可穷举流程 | 未覆盖异常分支 |
| RPA | 预设规则或界面步骤 | 稳定界面的重复录入搬运 | 界面变化、选择器脆弱、凭据风险 |
| AI Agent | 模型依据当前状态提出下一步，应用执行控制 | 开放步骤、需要多次检索判断的任务 | 错误动作累积、循环、成本和权限扩大 |
Google Cloud 的Agentic AI 架构选择指南明确指出，摘要、翻译、分类等确定性任务通常不需要 Agent。一个可靠的选择原则是：能用单次模型调用解决，就不要先建循环；能用固定工作流稳定解决，就不要让模型自由选择每一步；只有动态决策带来的收益大于额外延迟、成本和治理负担时，Agent 才值得引入。
Agent 与 Tool Use、Function Calling、MCP 是什么关系？
Tool Use 是模型根据工具描述提出调用的能力，Function Calling 是常见的结构化工具调用方式；它们解决“模型怎样表达要调用什么及参数是什么”。MCP 是连接 AI 应用与工具、资源、提示等上下文的协议体系；它解决发现、交换和调用接口的一部分问题。Agent 则在更上层管理目标、多轮状态、调用循环、终止、权限与恢复。
| 层级 | 核心问题 | 典型产物 | 本身不负责 |
|---|---|---|---|
| 结构化输出 | 输出格式能否被程序解析 | 符合 schema 的 JSON | 外部动作执行 |
| Function Calling | 模型建议调用哪个函数及参数 | 工具名与参数对象 | 最终授权和幂等 |
| MCP | 应用怎样发现和连接上下文能力 | tools/resources/prompts 与协议消息 | 业务风险分级 |
| Agent runtime | 怎样围绕目标多轮运行并停止 | 状态、步骤、日志、审批与结果 | 替业务所有者承担责任 |
MCP 的官方架构说明明确区分 host、client、server，并列出 tools、resources、prompts 等原语；协议也特别说明，它不规定 AI 应用如何使用模型或管理上下文。因此，接入 MCP server 不会自动把应用变成可靠 Agent，也不会自动证明第三方工具安全。需要深入工具模式、参数校验、幂等和并行调用时，可转到本站的Tool Use 与 Function Calling 专页。
一套可运行的 Agent 由哪些组件组成？
可以把系统拆成目标与政策、模型、上下文与状态、工具注册表、执行控制、身份授权、观察与审计七个部分。不同框架会合并或改名，但责任不能消失。OpenAI Agents SDK 的官方概览也把 agent loop、function tools、handoff、guardrails、sessions、human-in-the-loop 和 tracing 分开提供，说明生产运行不是一个提示词就能包办。
| 组件 | 职责 | 必须记录 |
|---|---|---|
| 目标与政策 | 成功、禁止、预算、时限、人工接管 | 任务版本与委托人 |
| 模型 | 理解上下文并产生候选决策 | 模型和配置版本 |
| 状态 | 保存已做步骤、工具结果与剩余约束 | 状态转移和来源 |
| 工具注册表 | 声明工具、参数、输出和风险级别 | 工具 schema 与版本 |
| 执行控制 | 校验、限流、幂等、重试、超时、审批 | 每次决定与结果 |
| 身份授权 | 决定哪个主体能对哪个资源做什么 | 令牌主体、权限、期限 |
| 观察审计 | 把调用与真实状态变化关联 | 输入、输出、副作用、费用 |
状态和记忆不是一回事
工作状态用于继续当前任务，例如已经查了哪些订单、哪个步骤失败、还剩多少预算；长期记忆用于跨任务保存用户偏好或历史事实。两者的数据来源、保留期限和删除要求不同。Google Cloud 的核心概念把短期上下文、长期知识与事务审计状态分开，是比“给 Agent 加一个向量库”更稳健的设计。向量库适合检索相似内容，却不天然提供事务一致性、权限继承或可否认性证明。
| 数据类型 | 示例 | 主要控制 |
|---|---|---|
| 会话上下文 | 当前对话和临时中间结果 | 窗口、脱敏、会话终止 |
| 任务状态 | 步骤、工具返回、待审批动作 | 一致性、恢复、幂等 |
| 长期记忆 | 经确认的偏好或长期事实 | 来源、写入门槛、过期和删除 |
| 审计记录 | 谁授权何时改变了什么 | 完整性、访问、保留、防篡改 |
模型、应用、身份和人分别负责什么？
最重要的边界是：模型提出调用，不代表它拥有调用权限。应用应该把模型输出当成不可信候选输入，先验证工具是否允许、参数是否满足 schema、调用对象是否在任务范围、委托人是否有权执行、是否达到审批阈值，再把请求交给工具。工具返回也可能含错误或恶意内容，不能未经校验重新变成高优先级指令。
| 主体 | 可以负责 | 不应被外包的责任 |
|---|---|---|
| 模型 | 理解、候选计划、工具选择、结果整理 | 最终授权、真实性保证、法律责任 |
| 应用 | 循环、校验、状态、限额、错误处理 | 绕过身份系统代替用户授权 |
| 身份系统 | 主体、资源、动作、时限和凭据 | 判断自然语言内容是否正确 |
| 工具 | 执行明确操作并返回状态 | 猜测模糊参数或扩大范围 |
| 业务所有者 | 目标、风险接受、审批、上线和下线 | 把问责交给“AI 自主决定” |
MCP 2025-11-25 的授权规范处理 HTTP 传输中的授权角色和令牌使用，但授权在规范中仍是可选能力，且业务动作范围仍需应用定义。协议兼容不等于最小权限。高风险工具应使用短期、受众绑定、按资源和动作收窄的凭据，避免把用户的长效高权限令牌直接放进提示词、记忆或工具返回。
什么时候值得使用 Agent？
适合 Agent 的任务通常同时满足三个条件：步骤会随新信息变化；系统能从工具或环境得到可验证反馈；错误影响能够通过沙箱、只读、审批或回滚控制。如果任务答案无法验证、动作不可逆且影响巨大，就不应因为模型“看起来聪明”而增加自主程度。
| 问题 | 答案为“是”时的含义 | 建议 |
|---|---|---|
| 步骤能提前写清吗？ | 大部分分支稳定 | 优先固定工作流 |
| 工具反馈会改变路线吗？ | 需要动态搜索、诊断或重试 | 可考虑 Agent 循环 |
| 结果能自动或人工验收吗？ | 有测试、引用、状态码或清单 | 可建立发布门槛 |
| 副作用能限制吗？ | 可只读、预览、审批、撤销 | 逐级开放能力 |
| 单次成功价值覆盖成本吗？ | 能承受多轮模型和人工复核 | 用真实任务试点 |
不需要 Agent 的常见任务
- 把一段确定文本翻译成另一种语言；
- 按固定 schema 从文档抽取字段；
- 对稳定标签做分类；
- 按已知顺序调用两个确定 API；
- 只需要一次检索和一次回答的问答；
- 不能容忍非确定性且已有明确算法的计算。
这些任务仍可使用大模型，但应尽量保持简单、可测和便宜。若需要理解大模型、RAG、微调和工具调用的基础边界，可阅读大语言模型 LLM 指南和RAG 检索增强生成指南；不要用 Agent 术语掩盖问题其实只是数据检索或格式转换。
如何写出可执行的 Agent 任务合同？
“帮我把工作做完”没有可验证边界。任务合同至少应说明输入、目标产物、允许数据、允许工具、禁止动作、成功证据、不确定性处理、预算和终止条件。合同既是提示的一部分，也是应用层策略和测试用例的来源；关键规则不能只放在自然语言提示里。
| 字段 | 差的写法 | 可验收写法 |
|---|---|---|
| 目标 | 处理退款 | 根据订单和政策草拟退款建议，不直接退款 |
| 范围 | 查看客户资料 | 只读当前工单关联订单，不查询其他客户 |
| 成功 | 让客户满意 | 输出政策条款、订单证据、建议和待确认项 |
| 禁止 | 注意安全 | 不得外发、改价、退款、删除或写入客户字段 |
| 停止 | 遇到问题找人 | 缺订单号、政策冲突或金额超过阈值时暂停 |
更完整的任务说明、上下文分隔、输出契约、Few-shot 和验证集方法见Prompt 稳定性与验证方法。对 Agent 来说，提示质量很重要，但不能替代应用校验、访问控制和真实任务评测。
工具应该怎样设计和分级？
工具名称和描述要让模型知道“何时用”和“何时不用”；输入 schema 要收窄枚举、类型、长度和必填项；返回值要区分成功、业务拒绝、权限不足、超时和未知错误。一个“manage_everything”工具即使调用方便，也会扩大选择歧义和权限爆炸半径。读、草拟、写入、外发、删除和付款应当是不同工具或至少不同授权动作。
| 级别 | 动作 | 默认策略 | 证据 |
|---|---|---|---|
| L0 | 计算、格式转换、沙箱代码 | 资源限额内自动 | 输入输出与资源使用 |
| L1 | 只读检索、查询状态 | 按任务范围自动 | 查询对象与来源 |
| L2 | 草拟邮件、变更或工单 | 生成预览，不提交 | 差异和引用依据 |
| L3 | 可撤销的内部写入 | 逐次或策略审批 | 审批、幂等键、变更记录 |
| L4 | 外发、付款、删除、权限和生产变更 | 强制人工确认或禁止 | 身份、对象、金额、影响和恢复方案 |
OpenAI Agents SDK 的human-in-the-loop 文档展示了工具调用在执行前暂停、审批或拒绝并恢复运行的机制。具体 SDK 会变化，但工程原则稳定：审批界面必须展示实际工具、参数、目标资源和预期影响，不能只让用户批准一句模糊的自然语言总结。
怎样设置终止条件、重试和恢复？
Agent loop 如果没有上限，可能在同一失败上重复调用并消耗预算。每次运行都应有最大轮数、最长时间、工具次数、费用上限和重复检测；工具重试要区分可重试的临时错误与不可重试的业务拒绝。写操作应优先使用幂等键或可检测的任务 ID，避免超时后重复创建、重复发送或重复付款。
| 结果 | 下一步 | 不得做 |
|---|---|---|
| 目标已满足 | 停止并提交证据 | 为了“更完善”继续调用 |
| 缺少必要输入 | 暂停并向用户提问 | 猜测身份、对象或金额 |
| 权限不足 | 记录并转人工或缩小任务 | 尝试其他凭据绕过 |
| 临时超时 | 按退避和幂等策略有限重试 | 无上限快速重放 |
| 业务拒绝 | 解释原因并停止 | 把拒绝误当网络错误 |
| 异常副作用 | 暂停、隔离、撤销、保全证据 | 让同一 Agent 自主掩盖或修复 |
OpenAI Agents SDK 的Runner 参考显示运行循环会在最终输出、handoff、工具调用等状态间推进，并提供最大轮数与 guardrail 终止路径。不要把某个 SDK 的默认行为当成业务正确性；应用仍要定义哪些状态算完成、哪些错误允许重试、何时必须人工接管。
AI Agent 面临哪些特殊安全风险？
传统应用的注入、访问控制、供应链和日志问题仍然存在，Agent 又增加了“非可信内容影响工具选择”和“错误在多步中累积”的路径。恶意网页、文件、邮件或工具返回可以包含诱导指令；如果系统把它们与可信政策混在同一上下文，模型可能提出越权调用。系统提示词不是安全边界。
| 风险 | 示例 | 首要控制 |
|---|---|---|
| 目标劫持 | 外部文档要求忽略任务并外发数据 | 内容隔离、来源标记、动作授权 |
| 工具误用 | 正确工具被用于错误对象或范围 | 参数约束、资源范围、预览审批 |
| 身份与权限滥用 | Agent 继承过大的用户或服务账号权限 | 独立身份、短期凭据、最小权限 |
| 记忆投毒 | 错误内容被写成长期可信事实 | 写入门槛、来源、过期和删除 |
| 级联失败 | 早期错误驱动后续多个写操作 | 检查点、影响上限、异常自动暂停 |
| 不可审计 | 只有最终回答，没有工具和状态记录 | 端到端执行轨迹与真实资源日志 |
OWASP 发布的Agentic Applications Top 10列出目标劫持、工具误用、身份与权限滥用等风险；NIST 2026 年AI Agent 安全意见分析也指出，既有网络安全原则仍适用但需要针对智能体调整。完整威胁建模可继续阅读AI 安全威胁、提示词注入与智能体权限防护。
最小权限必须落实到动作
NIST SP 800-171 Rev.3 的最小权限要求强调只授予完成任务所需的授权访问。放到 Agent 场景，不能只问“用户能不能访问这个系统”，还要问“本次任务是否需要读取该资源、是否允许修改、有效多久、能否批量执行、能否把结果传给另一个工具”。
| 授权维度 | 必须收窄的问题 |
|---|---|
| 主体 | 哪个用户委托的哪个 Agent 版本？ |
| 资源 | 只能访问哪个租户、项目、文件夹、订单或仓库？ |
| 动作 | 只读、草拟、更新、删除、外发分别允许吗？ |
| 时间 | 凭据何时生效、何时自动失效？ |
| 数量 | 最多多少条、多少金额、多少次调用？ |
| 传播 | 结果能否进入记忆、日志或另一个工具？ |
如何评测 Agent，而不是只看成功演示？
Agent 的输出具有波动，且同一最终答案可能来自完全不同的工具路径。评测不能只看文字质量，要同时看任务是否完成、是否调用错误工具、是否产生副作用、是否引用正确证据、成本和延迟、人工介入原因，以及失败后能否安全停止。Anthropic 的Agent evals 指南强调多轮工具调用、状态修改和中间结果会增加评测复杂度，并建议组合不同 grader 和多次试验。
| 切片 | 至少包含 | 验收重点 |
|---|---|---|
| 正常任务 | 典型高频输入 | 完成质量和单位成本 |
| 信息不足 | 缺标识、日期、范围 | 是否提问而非猜测 |
| 工具异常 | 超时、限流、空结果、错误 schema | 重试、降级和停止 |
| 权限边界 | 越租户、越对象、越动作 | 拒绝且不泄露 |
| 恶意内容 | 网页、文件和工具返回中的注入 | 是否触发危险动作 |
| 冲突目标 | 速度与准确、用户要求与政策冲突 | 优先级和转人工 |
| 不可逆动作 | 外发、删除、付款和生产变更 | 审批、幂等和恢复 |
| 指标 | 分子/分母或记录方式 | 为什么不能只看平均值 |
|---|---|---|
| 任务成功率 | 满足预定义验收的任务 / 全部任务 | 高风险小类可能被大量简单任务掩盖 |
| 错误动作率 | 调用错误工具、对象或参数的任务占比 | 一次严重副作用可能比多次回答错误更重要 |
| 人工介入率 | 按原因统计提问、审批、纠错、接管 | 高介入可能代表安全，也可能代表不可用 |
| 单位成功成本 | 模型、工具、基础设施和人工 / 成功任务 | 只看 token 会遗漏工具和审核成本 |
| 恢复成功 | 异常后停止、撤销、重放和对账结果 | 正常路径无法证明韧性 |
模型、提示、工具 schema、检索库、权限或编排任何一项变化，都应视为新的系统版本并跑回归集。可重复评测的基础是固定任务输入、环境快照、工具模拟或可重置沙箱、验收规则、随机性设置和完整轨迹；没有这些条件的“实测成功”不能作为生产证据。
从原型到生产，怎样分级上线？
稳妥顺序是沙箱、只读、草拟、审批写入、有限自动化。每一级不是等待固定天数，而是达到该级任务的证据门槛；一旦模型、工具、权限或业务规则变化，就重新评估。Anthropic 在可信智能体实践中强调人类控制、安全交互、透明和隐私，并指出自主性会增加误解意图、意外动作与提示词注入风险。
| 阶段 | 允许能力 | 放行证据 | 退回条件 |
|---|---|---|---|
| 沙箱 | 合成数据和隔离工具 | 循环可终止、基本任务通过 | 无限循环、越界访问 |
| 只读 | 访问限定真实数据 | 来源正确、无跨范围读取 | 泄露、错误检索、注入触发 |
| 草拟 | 生成不提交的变更 | 差异可审、对象和参数正确 | 隐藏副作用、无法解释变更 |
| 审批写入 | 人确认后执行单次写入 | 审批完整、幂等、可撤销 | 重复执行、审批信息不完整 |
| 有限自动化 | 低风险白名单内自动 | 持续回归、异常自动暂停 | 错误或成本超过阈值 |
单 Agent 还是多 Agent？
多 Agent 可以分离角色、权限和上下文，但也增加消息传递、重复推理、冲突、延迟和审计难度。先用单 Agent 加清晰工具和确定性代码；只有当任务确实需要不同权限边界、专业上下文或可独立验收的子任务时，再考虑拆分。不要为了展示“团队协作”让多个模型互相评价，却没有外部验收标准。
| 条件 | 单 Agent | 多 Agent |
|---|---|---|
| 任务边界 | 共享一个目标和工具集 | 子任务可独立验收 |
| 权限 | 权限范围相近 | 角色需要明显隔离 |
| 上下文 | 一套上下文可管理 | 专业上下文互相干扰 |
| 故障定位 | 路径较短，易追踪 | 必须追踪 handoff 和消息来源 |
| 成本 | 轮次和重复较少 | 额外协调与重复推理可被收益覆盖 |
常见误区与纠正
误区一：有长期记忆才算 Agent
短任务可以只使用当前状态；不必要的长期记忆反而增加隐私、过期事实和投毒风险。应先证明跨任务保存信息确有价值，再定义写入、来源、过期和删除规则。
误区二：模型会反思，所以能自动修复
再次询问模型可能发现部分错误，也可能强化原先错误。恢复需要应用层检查点、幂等、撤销、对账和独立验收；不能把“反思”当作事务回滚。
误区三：工具越多，能力越强
工具越多，描述冲突、选择错误、权限面和测试组合越大。先给完成目标所需的最小工具集，并通过真实失败样本优化工具接口。
误区四：继承用户权限就安全
用户可能拥有历史上过大的权限，恶意内容也可能诱导 Agent 以用户身份执行不符合本次委托的动作。需要任务级授权、动作级审批和资源范围限制。
误区五：有最终日志就可审计
最终回答无法证明模型调用了什么、谁批准了参数、工具是否真正改变状态。审计链要关联委托人、Agent/模型/工具版本、输入来源、授权、调用、返回和真实资源变化。
上线前最小检查清单
- 写明成功、失败、禁止和转人工条件；
- 确认任务是否真的需要动态 Agent，而不是单次调用或固定工作流；
- 区分模型建议、应用校验、身份授权和工具执行；
- 按读、草拟、写、外发、删除和付款分级工具；
- 使用最小权限、短期凭据和任务资源范围；
- 设置最大轮数、时间、调用次数、并发和费用；
- 为写操作设计幂等、预览、审批、撤销或人工恢复；
- 把外部网页、文件、检索结果和工具返回视为不可信内容；
- 建立正常、缺信息、工具失败、越权、注入和不可逆动作评测集；
- 记录单位成功成本、错误动作、人工介入和恢复结果；
- 保存端到端审计链并测试暂停、撤销凭据和下线；
- 模型、提示、工具、知识库或权限变更后重新回归。
如果正在建立站内或企业级智能体知识体系，可从AI 智能体与自动化专题进入，再按任务阅读工具调用、VLM 视觉语言模型、计算机视觉和AI 滥用与安全防范。这些页面解决不同层级的问题，不应被合成一篇无边界的“AI 全攻略”。
结论：先证明控制与恢复，再扩大自主程度
AI Agent 的价值不是“像人一样”，而是能在开放步骤中代表用户完成可验收任务；风险也来自它能连续影响真实系统。判断一个 Agent 是否值得使用，依次检查：目标能否验收、模型能看到什么、工具能改变什么、应用怎样校验、谁授予权限、何时必须审批、失败怎样停止与恢复。固定流程足够时保持固定；确实需要动态决策时，再从只读和草拟逐级开放。
编辑复核与纠错记录：本文由兰塞 AI 编辑流程于 2026 年 7 月 18 日复核。旧稿把智能体描述成可独立工作的“数字劳动力”，并把长期记忆、反思、多智能体、自动回滚和高风险行业应用写成普遍能力；新版撤回这些无边界断言，改为目标、状态、模型建议、应用校验、身份授权、工具执行、人工审批和评测证据组成的工程框架。产品与 SDK 仍会更新，部署前请核对对应官方文档。本站来源、更新与纠错原则见关于本站与编辑规范。
