工作中如何选择 AI Agent：一份实用评估清单

最好的 AI Agent，不是功能列表最长的那个，而是能以可接受的质量、风险、速度和成本，完成一项具体工作的那个。

这句话看起来理所当然，但很多选型从一开始就走偏了：团队先比较模型、观看精心准备的演示、统计集成数量，却没有先统一要改善的任务。结果是，产品在受控场景中表现惊艳，进入真实工作后却被例外情况、权限限制和不完整数据拖住。

下面这套清单适用于研究、编程、销售、客服、运营类 Agent，也适用于具备 Agent 能力的通用助手。它的目的不是做一张“大而全”的评分表，而是帮助你用真实任务做出判断。

先定义工作，再看产品

打开厂商页面之前，先用可执行的语言写下一项任务。

模糊定义：

我们需要一个 AI 销售 Agent。

可评估定义：

对符合资格规则的入站客户，生成带来源的账户简报，列出缺失信息，起草个性化首封邮件，并等待销售人员批准后再发送。

第二种写法给出了输入、交付物、边界和责任人，也说明研究与起草可以委托，发送仍由人控制。

适合试点的任务通常满足五个条件：

• 发生频率足够高，能够测量；
• 消耗明显时间，或经常让下一个环节等待；
• 包含固定自动化难以处理的模糊性；
• 负责这项工作的人能判断结果是否合格；
• 试点期间的错误可以被限制在小范围内。

如果连工作都没有定义清楚，就无法公平比较 Agent，最后评估的只是演示能力。

1. 任务匹配：能否完成一个真正有用的工作单元

很多产品只在某个孤立步骤上表现出色。研究 Agent 能找到资料，却交付不了可用简报；客服 Agent 能起草回复，却无法查看账户或更新工单；代码 Agent 能生成代码，却不会运行项目检查。

把真实任务从触发条件一直画到可验收结果，再标出 Agent 能独立完成哪些步骤、哪些需要额外集成、哪些仍需人工处理。

优先寻找能产生价值的最小完整单元。“总结文档”可能只节省几分钟；“把合同与公司政策逐条核对，引用每一处偏差，并生成审核表”才可能真正解除瓶颈。

还要测试正常路径被打断时会发生什么。它能否询问缺失信息、换用另一个可靠来源、安全重试失败工具，或者带着清楚说明把任务交回？只能处理完美输入的系统更像演示，而不是可靠执行者。

2. 输出质量：能否稳定达到你的验收标准

不要因为一次回答“看起来很聪明”就给高分。应该从真实工作中准备一组小型测试集，至少包含：

• 三个普通案例；
• 两个困难但有效的案例；
• 两个信息缺失或互相冲突的案例；
• 一个应该拒绝或升级给人的请求；
• 一个连接工具失败的案例。

先写验收条件，再运行测试。研究简报可以评估事实准确性、来源质量、必答问题覆盖、事实与推断是否分开、不确定性是否显式；代码任务可以评估测试是否通过、修改是否越界、未解决风险是否说清楚。

条件允许时，做盲评。去掉产品名称，让平时负责这项工作的人直接评价结果。稳定做到 80%、并清楚暴露限制的系统，可能比时而惊艳、时而危险的系统更有价值。

同时记录人工修复频率。生成节省的时间，很容易在核验和返工中被全部吃掉。

3. 集成能力：能否在工作实际发生的地方运行

集成列表上的 Logo 不能证明可用。必须确认它支持哪些对象、哪些字段、哪些动作。

以 CRM 为例，要问 Agent 能否读取自定义字段、获取活动历史、遵守记录级权限、写入备注、更新阶段，以及能否在你的部署环境中工作。“支持 Salesforce”可能只是一个搜索入口，也可能意味着过宽的管理权限，两者完全不同。

关键系统优先选择由产品方持续维护的原生集成。当团队能够承担实现和监控责任时，API 或 MCP 连接也可以使用，但“你们可以自己开发”不能算作已经存在的能力。

必须在真实沙箱中测试认证、凭证过期、速率限制、分页、重复动作和部分失败。真正的问题不是“能否连接”，而是“当连接表现得像生产环境一样不完美时，能否可靠完成任务”。

4. 权限与数据边界：它能看见什么、修改什么

Agent 只应获得完成任务所需的最小权限。

把权限按能力拆开审查：

• 访问公开网络；
• 读取内部数据；
• 修改内部数据；
• 对外沟通；
• 执行代码或命令；
• 采购或财务动作；
• 接触个人、受监管或机密数据。

读写权限不应默认捆绑。研究 Agent 可能需要查看客户记录，但不需要修改；客服 Agent 可以提出退款建议，却不应该直接执行无上限退款。

继续确认权限是按用户、Agent、工具还是环境设置；凭证如何保存；数据是否用于模型训练；内容保留多久；不同客户或员工的上下文如何隔离。

这不是理论风险。OWASP 将过度代理能力归因于功能、权限或自主程度过高。当模型发生误判或受到恶意内容操纵时，这些过度能力会直接转化为破坏性动作。

5. 人工控制：Agent 在哪里停下来

审批应根据动作影响设置，而不是在所有步骤最后机械加一个“确认”。

可以先把动作分级：

• 低风险： 读取公开资料、整理私人笔记、运行可撤销分析。
• 中风险： 修改内部草稿、更新非关键记录、创建待审核代码变更。
• 高风险： 联系客户、发布内容、删除数据、修改权限、部署软件或花钱。

成熟产品允许为不同工具设置不同审批策略。请求确认时，它应当展示准备执行的动作、相关上下文以及可能后果，而不只是弹出一句“是否继续”。

还要测试拒绝路径：审核人不同意后，Agent 能否修改方案或干净结束？审批超时或负责人不在线时会怎样？人在回路只有在压力下仍然清楚可控，才算真正的安全机制。

OWASP AI Agent 安全清单建议，在不可逆操作中把决策与执行分离，并为高影响动作保留人工审核。

6. 可观测性与失败处理：能否还原发生过什么

当 Agent 给出错误结果时，“模型就是这么决定的”不能成为事故说明。

运营人员至少应能查看：

• 原始任务和当时使用的指令版本；
• 调用过的工具及关键参数；
• 使用过的来源或业务记录；
• 请求过哪些审批、由谁批准；
• 重试、错误与降级行为；
• 总耗时与成本；
• 最终产物和完成状态。

日志应能支持调查，同时避免泄露凭证和不必要的个人信息。执行轨迹本身也可能包含敏感数据，必须遵守与业务系统相同的访问控制。

测试工具超时、响应格式异常、证据冲突、速率限制和模型拒绝。Agent 不应该在失败后悄悄声称任务完成。合格的失败结果，应包含足够信息，让人可以继续处理。

还要确认是否存在硬限制：最长运行时间、最多工具调用、重试次数、花费和递归深度。陷入循环不仅是稳定性问题，也是成本问题。

7. 安全与治理：控制是否真正进入系统

安全认证和问卷有价值，但 Agent 带来了更具体的问题。

要问产品如何处理来自网页、邮件、文档和其他 Agent 的不可信内容。这些内容可能夹带指令，试图改变任务目标或诱导系统泄露数据。身份和权限判断必须由软件控制强制执行，不能只靠提示词提醒模型“记得遵守规定”。

企业选型至少应审查：

• 身份体系与单点登录；
• 角色权限和环境隔离；
• 加密、保留与删除策略；
• 数据驻留和子处理商；
• 审计导出和事故响应；
• 提示词注入测试；
• 代码执行与浏览器会话隔离；
• 员工离职和账户关闭后的数据处理。

NIST 的AI Agent 标准计划把互操作性、Agent 身份、授权和安全评估放在一起推进。即使标准仍在发展，这些问题也已经可以直接作为采购条件。

不要接受一句笼统的“企业级安全”。要求对方说明具体控制、适用范围，以及它在你计划采用的部署方式中如何被验证。

8. 总成本：一个通过验收的任务到底花多少钱

每席位或每 Token 价格通常无法反映真实成本。

应该计算“每个通过验收的任务成本”，包括：

• 订阅与平台费用；
• 模型和 Token 消耗；
• 工具或 API 费用；
• 配置与集成工作；
• 监控和管理；
• 人工审核与修正时间；
• 失败运行和重复工作。

延迟也要记录。一个便宜但要运行 40 分钟的 Agent，可能适合隔夜研究，却不适合实时客服。

确认产品是否支持预算、并发和失控任务限制；套餐限制的是消息、模型调用、工具调用、计算时长，还是完成任务数；在预期规模下，费用是否仍可预测。

比较基准也不是“Agent 与零成本”。应该与现有流程比较：人工时间、等待时间、返工、错失机会以及错误代价。

一张简单的评估计分表

不同能力不应平均计分。建议先设置权重：

评估项	建议权重	需要收集的证据
任务完成与质量	30%	代表性案例的真实结果
集成可靠性	15%	沙箱运行和失败测试
权限与数据控制	15%	配置审查和访问测试
人工审批与可撤销性	10%	高风险动作场景
可观测性与恢复	10%	执行轨迹、告警和失败记录
安全与治理	10%	控制文档与验证结果
总成本与延迟	10%	每个合格任务成本

权重应随任务变化。处理健康数据时，安全可能占 25%；实时语音 Agent 则可能把延迟放在首位。重点是在演示影响判断之前，先把优先级写清楚。

淘汰条件需要单独列出。总分再高，也不能弥补租户隔离缺失、写权限无限制或无法导出必要审计记录。

用七天试点获得真实证据

判断 Agent 是否合适，不需要先做三个月转型项目。

第一天：定义任务

指定一个负责人，记录当前流程、成功标准，以及试点期间绝对禁止的动作。

第二天：准备测试集

收集十个代表性案例，删除不必要的敏感信息，并写下预期结果和已知陷阱。

第三天：配置最小权限

连接沙箱或只读账户，设置工具、时间、重试和成本上限，对外或不可逆动作必须审批。

第四至第五天：运行并观察

对同一批案例保持一致指令，不要每次临时辅导。记录质量、人工介入、耗时、成本和失败。

第六天：测试边界

加入缺失数据、冲突证据、集成失败、文档中的恶意指令，以及超出 Agent 职责的请求。

第七天：做出决定

把结果与当前流程比较，只选择四种结论之一：淘汰、针对明确问题修改后重测、在监督下部署，或扩大试点。

试点成功的标志是得到清晰决定，而不是得到一场好看的演示。

需要放慢采购的危险信号

如果供应商无法直接回答以下问题，应当谨慎：

• 哪些动作是真正自主的？
• 读取和写入权限能否分开？
• 工具在任务中途失败会怎样？
• 能否查看并导出执行轨迹？
• 能否只对某一种动作要求审批？
• 如何隔离网页和文档中的不可信指令？
• 单次任务最大花费和工具调用次数是多少？
• 如何删除已保存的任务数据与记忆？
• 年度合同前能否用自己的案例测试？

其他警示包括：演示只使用理想输入、集成描述模糊、没有明确拒绝行为、缺少硬限制，以及无法换算成单任务成本的定价。

最终决定应落在具体任务上

不要试图为整个公司选择唯一“最强 Agent”。代码、客服和市场研究运行在不同环境中，需要的证据和控制完全不同。

选择那个能够完成边界任务、适配现有系统、如实暴露失败，并接受你所需权限限制的产品。即使大部分步骤由 Agent 执行，流程仍要有明确的人类责任人。

成熟的采购问题不是“它有多自主”，而是“我们可以负责任地信任它完成什么工作，这份信任由哪些证据支持”。