一、引子：Agent 从概念走向生产
本文所说的 AI Agent，指具备规划、调用工具、多步执行能力的系统：它能拆解目标、自行决定下一步调用什么工具、连续执行多个动作直到任务结束。它不是"一问一答"的聊天机器人，也不是写死在代码里的固定流程（那叫 workflow）。
概念本身不新，但"从概念到生产"这一步，是目前绝大多数团队真正卡住的地方。Demo 阶段看的是"能不能跑通"，生产阶段看的是另外四件事：
- 可靠性：同一任务重复跑 100 次，结果分布如何？会不会一次对、一次错？
- 可观测：它每一步做了什么、调了什么工具、为什么这么选，能不能回溯？
- 可回滚：它做错了，能不能低成本撤销？
- 可治理：权限边界、成本上限、审计记录是否从第一天就存在？
厂商给出的定义，恰好也从"工具调用"这个动作层面划定了边界。⚑厂商口径——Anthropic 在《Building effective agents》（2024-12-19）中定义：
"Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." （出处：Anthropic 官方工程文章《Building effective agents》，2024-12-19）
注意这句话的两个关键词：**dynamically direct（动态指挥）**和 maintaining control（保持控制）。前者是"能动性"，后者是"可控性"。只做到前者是 demo，两者都做到才是生产。
核真备注：该文页首现已标注"2024 年 12 月以来，文中所述工具链已发生较大变化，现行做法见 Claude Managed Agents 及配套文档"。引用其定义与 workflow/agent 二分仍然有效，但框架选型建议需以厂商最新文档为准。
二、能力边界：什么任务适合先交给 Agent
先回答一个反直觉的问题：不是任务越"智能"越适合先上 Agent，而是任务越"可验证"越适合先上。
建议用三把尺子筛选候选任务：
| 尺子 | 要问的问题 | 好的信号 | 坏的信号 |
|---|---|---|---|
| 确定性 | 这个任务有没有明确的对错？ | 有标准答案或可自动判定的结果 | 结果好坏依赖主观判断 |
| 可逆性 | Agent 做错了，能否低成本撤销？ | 只读、草稿、可改派 | 已发出、已扣款、已改库 |
| 反馈闭环 | 有没有一个自动机制告诉它"对了还是错了"？ | 测试、校验、人工标注可回流 | 错误只能事后人工发现 |
按这三把尺子，可落地的候选任务清单如下：
| 任务 | 确定性 | 可逆性 | 反馈闭环 | 结论 |
|---|---|---|---|---|
| 工单分类与路由 | 高 | 高（改派即可） | 有（人工可标注对错） | 适合先做 |
| 代码生成 + 跑通单测 | 中 | 高（可回滚提交） | 有（测试即反馈） | 适合，但必须配测试 |
| 会议纪要 + 待办提取 | 中 | 高（人可校对） | 有（人工校对回流） | 适合，输出归人审 |
| 客服回复草稿 | 中 | 高（只出草稿） | 有（发送前人工把关） | 适合，但只做到草稿 |
| 自动发送对外邮件 | 中 | 低（发出收不回） | 弱 | 先做"草稿 + 人工发送" |
| 批量修改生产数据库 | 低 | 低 | 弱 | 不适合，至少先只读 + 审批 |
一个朴素的结论："先做只读、先出草稿、先跑测试"是 Agent 落地的最短路径。 对外、对钱、对生产数据的三类动作，一律后置。
三、可靠性与评测：如何度量"够不够好"
生产可靠性不能靠感觉，要靠三件套，缺一不可：
1. 任务完成率——但必须拆开报。 只报一个总成功率没有意义。要按任务类型、难度分级、工具组合拆分，并注明测试集、采样次数、评测方式。一个"成功率 90%"如果没有说明是在哪个测试集上测的、跑了多少次、怎么判对错，等于没报。
2. 轨迹（trace）评估——看过程，不看结果。 很多任务"结果对了"但"过程是蒙的"。要评估每一步的工具选择是否合理、有没有绕路、有没有越权调用。轨迹评估能抓出"结果对但路径错"的隐性失败，这些失败在生产里迟早会爆。
3. 回归测试集——防止"修好一个、坏掉一片"。 把历史失败样本沉淀成回归集，每次改 prompt、换模型、调工具都跑一遍。回归集必须可复现：同样的输入、同样的环境、同样的判分规则，能跑出同样的结果。
落地建议：公开评测集（如 SWE-bench、GAIA、tau-bench 等）只做横向参考，不替代自己的业务回归集。 因为公开集不覆盖你的真实工具、真实数据和真实失败模式。真正值钱的是你们自己踩过的坑，把它们固化进回归集。
四、人机协同：Human-in-the-loop 的设计取舍
HITL 的目标不是"让人盯住每个动作"（那就失去了自动化价值），而是把人的注意力花在风险最高、判断最难的地方。三个设计要素：
1. 审批节点——按风险分级，不是一刀切。 低风险动作（读数据、生成草稿）自动执行；中风险动作（改配置、批量操作）审批后执行；高风险动作（对外发送、资金、生产数据写操作）人工执行。风险分级要写进配置，而不是靠开发者临时判断。
2. 权限最小化——Agent 能调的，只给到任务所需。 Agent 的工具集应显式定义，能读的库不授写权限，能发草稿的账号不给群发权限。权限越界本身就是一种失败信号，应触发告警。
3. 可回滚——每一步都留退路。 写操作要有对应的撤销手段；对外动作要能撤回或改为草稿先行。回滚不是补救措施，是上线前的必要条件。
平衡点在于：自动化收益 = 省下的人工成本；HITL 成本 = 审批等待 + 人工兜底。 当某类任务的人工干预率长期稳定且错误率可接受时，再考虑放宽审批；反之收紧。审批节点要能随数据动态调整，而不是上线时定死。
五、成本与治理：token 成本、安全边界与审计
1. 单任务成本核算——算全链路，不算单次调用。 单任务成本 =（输入 token + 输出 token + 工具调用/检索的额外 token）× 单价 + 工具调用次数成本 + 人工兜底成本。多步 Agent 容易在"反复调用、重复读取上下文"上悄悄烧钱，只盯单次模型调用的价格会严重低估真实成本。
2. 错误放大风险——多步任务的级联失败。 单步任务错一步就是错一步；多步任务错一步可能连锁放大（错误的中间结果喂给后续步骤）。缓解手段：关键步骤设检查点、设任务级预算上限（token 或步数）、超出即熔断转人工。熔断要当成正常机制设计，而不是意外兜底。
3. 审计日志——从第一天就记。 每次运行至少记录：输入（脱敏后）、每一步的模型输出与工具调用、触发的权限与审批、回滚与人工干预。审计日志的目的不只是合规，更是复盘失败、训练回归集、核算成本的原材料。
治理原则落地清单：
- 每个 Agent 任务都有明确的权限清单与成本上限
- 写操作、对外操作有审批节点和回滚手段
- 审计日志覆盖输入、工具调用、审批、回滚全链路
- 失败样本自动进入回归集，评测可复现
- 单任务成本按月复盘，异常走高有告警
六、厂商口径与路线图
编辑部说明：本节所有厂商表述均已对照官方原文核实（核实日期见文末），并统一以 ⚑ 标注厂商口径。厂商引文原样引用、不作演绎；发布前建议再点一次原文链接（官方文档会持续更新版本）。
⚑ Anthropic 在《Building effective agents》（2024-12-19）中给出两个关键判断：
"Workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale." （出处：Anthropic 官方工程文章《Building effective agents》，2024-12-19）
即：任务定义清晰、路径固定时，workflow 更可预测、更稳定；需要灵活性和模型自主决策时，才轮到 Agent。⚑Anthropic 并归纳客户实践：最成功的实现往往采用简单、可组合的模式，而非复杂框架或专用库（出处同上，归纳大意；该文页首现已注明工具链变化，见第一节核真备注）。
⚑ OpenAI 在《A Practical Guide to Building Agents》（官方 PDF，2025 年发布，34 页）中给出定义：
"Agents are systems that independently accomplish tasks on your behalf." （出处：OpenAI《A Practical Guide to Building Agents》，官方 PDF）
并给出两条可操作特征：
"It leverages an LLM to manage workflow execution and make decisions... It has access to various tools to interact with external systems—both to gather context and to take actions—and dynamically selects the appropriate tools depending on the workflow's current state, always operating within clearly defined guardrails." （出处同上；省略号表示原文较长、此处截取，非改写）
这一表述的落点在于：Agent 用 LLM 管理工作流执行与决策，并在明确护栏（guardrails）内动态选择工具——这与本文"权限最小化 + 审批节点"的治理主张，是同一件事的厂商侧表述。
⚑ 微软 则在工具链层面推进：以 AutoGen / Semantic Kernel 提供 Agent 编程框架，以 Copilot Studio 提供低代码构建、测试与发布，并在 Azure AI Foundry 生态中面向生产托管推进 Agent 服务（微软侧口径归纳，非逐字引用；具体产品名与可用性以微软官方文档为准）。
关键数据表：厂商口径与生产实测分列
| 主题 | 厂商口径（原文或归纳，出处） | 生产侧实测 / 落地判断 |
|---|---|---|
| 什么是 Agent | ⚑Anthropic："Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."（2024-12-19） | 能"动态指挥 + 调用工具"只是起点；生产还要可观测、可回滚、可审计 |
| 何时用 Agent | ⚑Anthropic：workflow 适合定义清晰的任务，Agent 适合需要灵活性与规模化自主决策的场景（2024-12-19） | 任务边界清晰、路径固定时先用 workflow，别为"Agent"而 Agent |
| 构建复杂度 | ⚑Anthropic：最成功实现采用简单、可组合模式（归纳大意，2024-12-19） | 先单 Agent + 显式流程，验证收益后再叠加复杂度 |
| Agent 定义（OpenAI） | ⚑OpenAI："Agents are systems that independently accomplish tasks on your behalf."（《A Practical Guide to Building Agents》PDF，2025） | "独立完成任务"是目标；生产落地还需 guardrails、人审与回滚 |
| OpenAI 护栏 | ⚑OpenAI：Agent 在"clearly defined guardrails"内动态选择工具（同上） | 工具集、调用时机、护栏需显式定义，即权限最小化的接口层 |
| 微软生态 | ⚑AutoGen / Semantic Kernel / Copilot Studio / Azure AI Foundry 工具链（归纳，非逐字） | 选框架看"是否便于评测、追踪、权限控制"，不是看 demo 好不好写 |
| "高成功率"类宣传 | 各厂商 demo 常见"高成功率"表述，多未公开测试集与采样方式（未核实，不采信） | 以可复现评测为准：任务完成率 + 轨迹评估 + 自有回归集 |
七、结语：给编辑部的落地建议与跟踪指标
落地 Agent 的优先级建议一句话：先选"只读/草稿/可验证"的任务，用三件套评测，按风险分级做人机协同，第一天就把成本和审计建起来。
后续应持续跟踪的指标：
- 任务完成率：按任务类型、难度分级拆分，注明测试集与采样方式
- 轨迹通过率 / 关键步骤通过率：看过程，不看单一结果
- 人工干预率：HITL 触发率、审批驳回率，用于动态调整审批阈值
- 单任务全链路成本：token + 工具调用 + 人工兜底，按月复盘
- 回滚 / 失败事件数与恢复时长（MTTR）：衡量"出了事多久能恢复"
- 回归集新增失败数：衡量"修一处是否坏一片"
- 错误放大事件数：一次错误导致多步失败的事件，作为熔断优化的信号
应持续跟踪的信息源：
- OpenAI：官方博客与文档（《A Practical Guide to Building Agents》PDF 及 Agents SDK / Building agents 系列）
- Anthropic：官方工程文章（《Building effective agents》及后续 Claude Managed Agents 更新）
- 微软：Azure AI / AutoGen / Semantic Kernel / Copilot Studio 官方文档
- 公开评测集：SWE-bench、GAIA、tau-bench 等更新（仅作横向参考）
- 各厂商安全卡 / 系统卡：能力边界与风险声明
一句话收尾：Agent 的生产力不在它"有多聪明"，而在它"错得起、看得见、收得回、查得到"。 这四件事，才是从 demo 到生产的真正路线图。
核真附注（审核编辑）
- 核实日期：本次审核。Anthropic 两处原文引用已对照 《Building effective agents》 逐字核对（含 "on the other hand"）；"workflow vs agent" 一句逐字相符；"简单、可组合模式"为归纳大意。
- OpenAI 引文已对照官方 《A Practical Guide to Building Agents》PDF（34 页，2025 年发布）逐字核对，替换了初稿中无法溯源的表述与日期。
- 微软工具链表述为归纳性厂商口径，非逐字引用，已标 ⚑。
- SWE-bench、GAIA、tau-bench 为业界公开评测集，本文仅作横向参考用途，未引用具体得分数字。
