从“会回答”到“能完成任务”，真正变化的是系统架构，而不只是换了一个更聪明的模型。

图：LLM 与 Agent 的工作方式差异

为什么“聊天模型”还不等于 Agent

大语言模型很擅长理解和生成文字，但单独的模型通常只负责“给出下一段内容”。它不会天然拥有你公司的订单权限，不会自动记住跨会话状态，也不会真正执行付款、创建日历或修改代码。要把模型变成能完成任务的系统，需要在模型外面增加工具、状态、循环、权限和观测。

因此，Agent 的价值不是让回答更像人，而是把自然语言意图转成可追踪、可验证的行动。用户说“帮我处理退款”，系统要知道查哪张订单、适用哪条规则、是否需要人工审批、执行失败如何回滚，以及什么时候才算完成。

一、Agent 的六个核心部件

很多教程把 Agent 简化成“LLM + Tools”，这对演示够用，对生产不够。一个真正可运行的 Agent，至少要解决以下六件事：

模型与指令：理解目标、做出局部判断，并输出结构化决策。

工具：让系统能够搜索、查询数据库、读写文件、调用业务 API 或执行代码。

状态与记忆：保存当前进度、中间结果、已做决定和跨会话信息。

编排循环：决定下一步、重试、回退、重新规划以及何时停止。

安全边界：限制权限、校验输入输出，并在高风险操作前请求确认。

观测与评测：记录每一步 Trace，统计成本、延迟、成功率和失败原因。

二、Agent 为什么一定要有“循环”

Function Call 可以让模型发起一次工具调用，但复杂任务往往要连续完成多步。查到航班后要比较价格，选中后要读取乘客信息，付款前还要确认预算。每一步的返回值都可能改变下一步，因此系统必须反复执行“判断—行动—观察—更新”。

循环同时带来风险：模型可能反复搜索同一个问题，工具报错后不断重试，或者在没有明确完成条件时一直消耗 token。生产系统需要设置最大步数、总耗时、预算上限、重复动作检测和人工升级条件。

三、Workflow 和 Agent 的区别：谁控制下一步

Workflow 的路径由代码预先规定；Agent 的下一步由模型结合当前状态动态决定。前者更稳定、容易测试，后者更灵活、能够处理未预见的情况。

实际项目通常不会选择完全固定或完全自治，而是采用“确定性骨架 + 局部 Agent”的混合结构。例如客服系统用固定流程完成身份验证、工单分类和权限检查，只在复杂问题分析环节开放工具给 Agent，最终退款仍由规则引擎和人工审批控制。

四、Agent 常见的四种工作模式

ReAct：边判断边行动

ReAct 的基本节奏是“根据当前观察决定下一步，然后调用工具”。它适合工具结果不确定、需要持续调整的任务，例如故障排查和开放式调研。缺点是调用次数多，容易进入无效循环。

Plan-and-Execute：先拆解，再执行

模型先生成计划，再逐项执行；当环境变化或验证失败时触发重新规划。它适合长任务，也更容易展示进度，但不能把第一版计划当成永远正确。

Reflection：做完后再检查

生成者完成任务后，由同一个模型的审查角色或独立评审模型检查结果。它适合代码、报告、合同等有明确质量标准的任务。要避免“自己给自己打高分”，最好加入规则、测试或外部证据。

Multi-Agent：专业角色协作

多个 Agent 可以采用经理式分派，也可以互相 handoff。多 Agent 只有在任务可并行、上下文需要隔离或专业边界清晰时才值得使用；否则通常只会增加 token、延迟和调试难度。

五、Function Calling：Agent 的原子动作

模型并不会直接执行 Python 函数或业务 API。它只会输出结构化的调用请求，应用程序负责校验参数、检查权限、真正执行工具，并把结果重新放回上下文。

from openai import OpenAI
client = OpenAI()
tools = [{
"type": "function",
"name": "get_weather",
"description": "查询城市天气，仅用于天气问题",
"parameters": {
"type": "object",
"properties": {"city": {"type": "string"}},
"required": ["city"],
"additionalProperties": False
},
"strict": True
}]
response = client.responses.create(
model="your-model", input="查询上海天气", tools=tools
)
# 应用程序读取 tool call 后，再做参数校验、鉴权和真实执行

工具定义越模糊，模型越容易误选或传错参数。工具描述应说明用途、边界、参数格式、返回字段、失败类型和风险等级。对于删除、付款、发邮件等写操作，应在模型决策之外加入确定性的授权与确认。

六、状态、记忆与规划：让长任务不失控

所谓 Agent 记忆，通常不是修改模型参数，而是把信息写到数据库、文件、向量库或状态存储中，在需要时检索并重新注入。短期状态用于当前任务，长期记忆用于跨会话偏好、历史决策和经验。

记忆系统最难的不是“存”，而是“何时写、写什么、何时取、取多少”。把所有历史对话塞回上下文不仅昂贵，还可能把过期信息和错误结论带入当前决策。可靠做法是结构化保存关键事实，附带来源、时间和置信度，并允许用户纠正或删除。

规划应当围绕可验证的状态变化，而不是一份漂亮的文字清单。每个步骤需要明确输入、预期输出、完成条件和失败处理。工具结果不符合预期时，应更新状态并重新规划，而不是机械重复上一动作。LangGraph 等框架把状态、节点和边建模为图，正是为了让长任务可以持久化、恢复、分支和调试。

七、MCP：把 N×M 的定制接入变成标准连接

MCP 的 Host–Client–Server 架构

MCP 是连接 AI 应用与外部系统的开放标准。Host 是 Agent 应用，内部为每个 Server 创建一个 Client；Server 对外暴露工具、资源和提示模板。开发者可以把文件、数据库、GitHub、日历或内部系统封装成标准能力。

截至 2026 年 7 月，MCP 已拥有官方 Registry、多语言 SDK、Streamable HTTP 等远程连接能力，并持续完善 OAuth 2.1 授权和企业管理扩展。标准化并不等于自动安全：远程 Server 仍需验证来源，敏感能力必须使用最小权限、明确授权、审计和用户确认。

八、Function Calling、MCP 与 Skills 怎么分工

Function Calling 是单次结构化调用能力；MCP 是连接工具与数据的开放协议；Skills 则是可复用的任务方法、领域规范和行为指令。三者可以同时存在。

SKILL.md
---
name: production_incident_triage
description: 线上接口错误率升高时使用
allowed-tools:
- metrics_query
- log_search
- read_runbook
---
# 处理步骤
1. 先确认告警时间、接口和影响范围。
2. 查询错误率、P95、依赖服务和最近发布记录。
3. 只读排查；任何重启、回滚或扩容必须请求人工确认。
4. 输出证据、判断、风险和下一步建议。

Skills 目前并不是一个跨平台统一标准，不同产品对目录、元数据、触发方式和允许工具的实现不同。更稳妥的理解是：它是一种把团队经验、工作规范和输出模板模块化的工程方法。

九、A2A：让不同 Agent 互相发现和协作

A2A 负责 Agent 间协作，MCP 负责 Agent 使用工具

当专业 Agent 运行在不同服务、由不同团队维护、使用不同语言或框架时，普通的本地子 Agent 调用不再够用。A2A 通过 Agent Card 描述能力，通过 Task 管理长时间任务，并使用 Message 与 Artifact 交换过程信息和交付物。

参考文章写作时 A2A 仍处于早期阶段；截至 2026 年 7 月，官方文档已经发布 1.0.0 规范，项目由 Google 发起并捐赠给 Linux Foundation。A2A 明确不替代 MCP：MCP 标准化 Agent 到工具，A2A 标准化 Agent 到 Agent。

十、生产级 Agent 应该怎么落地

真正稳定的 Agent 往往不像一个“完全自由的机器人”，而像一个被软件工程严密包裹的决策组件。模型只在需要语义理解和动态判断的位置拥有自由度，身份、权限、预算、幂等、事务、审批和审计由确定性代码控制。

上下文治理：按任务构建上下文，区分可信指令、外部数据和用户输入。

工具网关：集中做鉴权、参数校验、限流、超时、重试、熔断和审计。

持久化状态：每个步骤都可以恢复，避免长任务因进程重启全部丢失。

模型路由：简单步骤用小模型，复杂规划和高风险判断用更强模型。

人工介入：低置信度、高金额、不可逆或敏感动作必须暂停并请求确认。

降级路径：Agent 失败时能回退到 Workflow、人工工单或只读建议模式。

十一、安全：Agent 最大的风险来自“能行动”

普通聊天模型答错，损失通常停留在文字层面；Agent 一旦拥有邮件、数据库、云资源或支付工具，错误就可能转化为真实操作。Prompt Injection 还可能藏在网页、文档或工具返回值中，引导模型忽略原任务并发起危险调用。

因此，不可信内容不能直接成为高权限动作的指令。外部文本应先提取成经过验证的结构化字段；敏感工具使用独立凭证和最小权限；高风险动作要求用户确认；所有调用保留身份、参数、结果和决策链。OpenAI 当前的 Agent 安全指南也强调结构化输出、隔离不可信数据、工具确认与多层防护。

十二、评测与可观测：Agent 不只看最终回答

Agent 的错误可能出现在任何一步：选择了错误工具、参数缺字段、搜索结果没有被正确使用、状态被旧信息污染、重试策略导致重复写入，或者最终答案看起来正确但实际并未完成操作。

评测应基于真实任务轨迹，既检查最终状态，也检查关键路径和安全约束。离线测试集需要包含正常、模糊、工具失败、权限不足、注入攻击和长任务恢复等样本；上线后继续采集 Trace，回放失败案例并加入回归集。

十三、什么时候该用 Agent

适合 Agent 的任务通常具备三个特征：目标明确但步骤无法完全预先写死；执行过程中需要读取外部结果再调整；错误能够被检测、限制和恢复。典型场景包括开放式调研、复杂客服处理、代码维护、跨系统运营和故障排查。

不适合高自治 Agent 的场景包括：固定报表、明确审批链、严格确定性计算、不可逆高风险操作，以及没有可靠评测标准的任务。此时更适合 Workflow、规则引擎或人机协作。

结语：Agent 的核心不是“自主”，而是“受控地完成任务”

把模型放进循环、接上几个工具，只能做出一个会演示的 Agent。真正能上线的系统，需要清晰的完成条件、面向模型设计的工具、可恢复状态、分层权限、人工审批、全链路 Trace 和持续评测。

最实用的路线通常是：先用 Workflow 跑通业务，再在确实需要动态判断的位置引入单 Agent；单 Agent 无法承载清晰的专业分工时，再考虑多 Agent；跨服务和跨团队协作时，再评估 A2A。复杂度应该由问题驱动，而不是由技术热度驱动。