这不是一句产品定义。我们用 xAgent 跑了一次受控项目周报任务，保留了持久化计划、任务进度、删除审批、生成产物、独立检查和修复计划。实验得到的关键结论是：Agent 能处理传统工作流难以预先穷举的材料冲突，但“任务已完成”仍不等于“结果已经正确”。

AI Agent 与 AI 自动化对比​

AWS 对两者的官方比较也把自动化概括为按照预定义规则快速、一致地完成任务，而 Agent 增加推理、适应和决策能力。真正影响落地的不是名称，而是你能否接受执行路径和结果存在不确定性。

什么是 AI 自动化​

AI 自动化通常把模型能力嵌入一个已知流程。例如：收到工单后分类，提取固定字段，匹配路由规则，再把记录写入指定队列。模型可能负责其中一步，但触发条件、步骤顺序、允许写入的位置和失败处理仍由系统预先定义。

当任务满足以下条件时，自动化通常更合适：

• 输入结构和业务规则稳定；
• 同一动作需要高频重复；
• 每个分支都能提前描述并测试；
• 输出必须严格符合字段、顺序或时限；
• 错误成本高，且不允许模型自行改变执行路径。

自动化的限制也很清楚：遇到两个来源互相冲突、信息缺失或用户目标需要重新解释时，流程只能执行预先设计的异常分支。没有这个分支，它不会自己发明一个可靠的处理办法。

什么是 AI Agent​

AI Agent 的核心不是聊天界面，而是目标驱动的执行循环：读取目标和上下文，形成计划，发现可用能力，调用工具，检查结果，再决定下一步。xAgent 会把 Agent、Skill、Tool、MCP、连接器、工作区和审批放在同一个服务端任务环境中。可按需加载能力，但“知道工具存在”不代表当前用户已经授权，也不代表调用可以绕过审批。详细边界见动态能力发现和审批与安全控制。

这类 Agent 更适合：

• 输入由多份文档、表格和自然语言要求组成；
• 中间步骤取决于前一步发现的内容；
• 需要区分事实、冲突、风险和待确认信息；
• 目标清楚，但无法提前穷举完整路径；
• 结果可以被人或程序再次检查。

Agent 的适应性来自模型判断，也因此引入了新的失败方式。它可能生成结构正确但事实过度概括的报告，也可能在没有真正解析文件时宣称“已验证”。这也是为什么 Agent 不能替代验证器、权限系统和审批策略。

什么时候应该使用哪一种​

先问五个问题，比先选产品更有效：

1. 路径能否提前穷举？ 能，就优先自动化；不能，再考虑 Agent。
2. 结果能否被检查？ 无法可靠检查的高风险任务，不应直接交给 Agent 自主完成。
3. 失败能否恢复？ 可重试、可回滚、可人工接管的任务更适合 Agent。
4. 变化发生在哪里？ 如果变化只在输入格式，用解析器或规则可能已经足够；如果变化涉及含义和下一步，Agent 更有价值。
5. 动作是否影响外部世界？ 删除、发送、付款、发布和修改业务数据应通过确定性工具与审批，而不是只依赖提示词。

最不适合 Agent 的场景通常是：规则非常稳定、吞吐量很高、每次都必须产生完全相同的结果，或者一次错误就不可逆。此时多一层模型判断只会增加成本和不确定性。

为什么生产方案通常是混合式​

“Agent 或自动化”是一个过于简单的选择题。更稳妥的生产结构通常分成三层：

这与 NIST AI 风险管理框架强调的可管理风险和可信性思路一致：治理不是在模型外面加一句“请谨慎”，而是把设计、使用和评估过程放进可以检查的控制体系。

一次真实的 xAgent 受控任务​

我们准备了两份虚构但内部一致的项目材料：会议记录和项目状态 CSV。任务要求 Agent 生成一份周报 Markdown 和一份七列行动项 CSV，同时满足三个约束：

• 不得虚构负责人、日期、进度、原因或决策；
• 两个来源冲突时，必须列出双方说法并标记为“需要确认”；
• 产物验证后删除一次性草稿，但必须遵循现有审批策略。

这个测试不衡量模型排行榜，也不声称代表所有 Agent。它只观察一个具体问题：当任务包含多来源证据、持久化计划、文件产物和高风险动作时，Agent 与确定性控制如何配合。

1. Agent 建立并推进持久化计划​

Agent 调用 plan_create 建立了六步修复前计划。界面持续显示已完成、当前和未开始的任务；每次 task_complete 都把焦点推进到下一项。这与只在消息里写一段“执行计划”不同：计划状态作为会话任务状态持续存在，用户可以在长任务中看到进度。

2. 删除操作进入审批，而不是被提示词放行​

当 Agent 尝试删除上传的一次性草稿时，fs_delete_files 没有因为任务文字里写了“可以删除”就直接执行。会话进入 waiting_approval，界面显示目标文件、风险等级和批准/拒绝按钮。用户批准后，原始工具调用才继续。

这说明提示词负责表达意图，审批策略负责决定动作是否可以执行。两者不是同一层。xAgent 的等待与恢复机制可在长任务指南中进一步查看。

3. 首次完成仍然没有通过独立验收​

Agent 最初报告两个文件“已经创建并验证”。但我们没有把这句话当作证据，而是重新打开 Markdown，并用真实 CSV 解析器导入行动项文件。检查发现四类问题：

1. 一段包含逗号的冲突说明没有加引号，七列 CSV 被解析为八列；
2. 一行少了一个空字段，后面的状态和依赖整体错位；
3. Markdown 的日期中混入了短横线之外的字符；
4. 执行摘要写了来源不支持的“进度正常”，且没有把行动项表放进周报正文。

这是 Agent 和传统自动化最重要的差异之一。工作流可以断言“工具返回成功”，但开放式产物还必须验证结构和语义。Agent 对自己的完成声明不能替代外部验收。

4. 缺陷进入新的持久化修复计划​

我们把具体缺陷、正确字段映射和验收条件发回同一个会话，要求先创建新的持久化修复计划，再原地修改两个文件。修复计划把 CSV 检查、修复、解析验证和 Markdown 检查、修复、复验拆成独立步骤。

修复后，CSV 被实际解析为 A1:G6：一行表头、五行数据、每行七列。冲突日期保留在同一个字段中，未分配的负责人和日期保持为空。Markdown 的日期、摘要、冲突表和行动项表也被重新打开核对。

这个闭环的价值不在于“Agent 第一次就做对”，而在于错误可以被发现、转成明确任务、持续修复并再次验证。

成本、可靠性与控制的取舍​

Agent 不应被当成更高级的自动化替代品。它把原来需要人处理的解释和路径选择交给模型，因此需要额外支付模型调用、上下文、重试和复验成本。路径越开放，成本和延迟越难预测。

同时，可靠性也不能只看一次最终答案。生产检查至少应覆盖：

• 来源完整性： 是否读取了全部输入，是否区分事实、冲突和缺失信息；
• 过程状态： 是否真的建立计划、调用工具并推进任务，而不是只输出叙述；
• 结构正确性： CSV、JSON、表格和文档是否能被真实解析器读取；
• 语义正确性： 摘要是否有来源支持，是否虚构负责人、日期或结论；
• 动作边界： 删除、发送和外部写入是否经过权限与审批；
• 恢复能力： 失败后能否保留上下文、原始调用和中间产物继续处理。

决策清单​

选择自动化、Agent 或混合方案前，可以直接使用下面的清单：

• 任务步骤是否稳定到可以写成流程图？
• 输入变化是格式变化，还是含义和目标变化？
• 有没有程序化验收条件？
• 错误是否可逆，是否允许人工接管？
• 哪些步骤必须是确定性的？
• 哪些动作需要用户或管理员审批？
• 是否需要保留计划、工具调用、来源和产物记录？
• 一次模型误判的业务代价是多少？

如果大部分步骤都能预先定义，就从自动化开始。如果主要难点是理解不同材料、决定下一步和处理异常，可以引入 Agent。如果任务既需要判断又会改变外部状态，通常应采用混合方案。

常见问题​

AI Agent 一定比自动化更好吗？​

不是。稳定、高频、规则清楚的任务通常更适合自动化。Agent 的优势是处理路径变化和语义判断，但它增加了成本、延迟和结果不确定性。

哪些任务不应该使用 AI Agent？​

不可逆、无法验收、要求完全确定结果，或能用简单规则稳定完成的任务，不应仅为了“智能化”而加入 Agent。高风险动作至少要有确定性工具、权限和人工审批。

AI Agent 能与工作流自动化一起使用吗？​

可以，而且这是常见的生产结构。Agent 负责理解目标、生成计划和处理异常；工作流负责校验字段、调用 API、重试和记录状态；人负责高风险确认。

AI Agent 会替代 RPA 或传统工作流吗？​

不会整体替代。Agent 可以决定何时调用既有流程，也可以处理流程未覆盖的输入，但批量、确定性和界面操作仍可能继续由 RPA 或工作流执行。

如何控制 AI Agent？​

不要只靠提示词。把模型能看到的数据、可用工具、工作区范围、外部连接、审批策略、任务状态和结果验证分别设计，并保留可审计的执行记录。