Agent自建还是买、评测怎么算能用、怎么不占业务时间——企业引入 Agent 要过的 5 道题
最近跟不少客户聊 Agent 评测的项目，但是发现在做评测之前，好像客户也只是内部有一个共识，一定需要测试，但是目标是什么，都不是很清楚，而且对到底是自建还是购买，也有很多疑虑
像刚做完数字化转型的、和正在做的，开口问的其实都是同一件事，AI 自动化到底该怎么落地。
但聊到后面我发现，表面上在问"怎么做评测"，底下压着的是同一个焦虑：钱花下去，怎么证明花对了，Agent能力到底行不行，能不能解决业务问题?
客户问得最多的 5 个问题
问题一 自建还是直接买？买的能满足自己业务吗
问题二 建好的 Agent 怎么算"能用"？评测验收标准怎么定
问题三 安全红线是通用的，怎么和垂类业务结合
问题四 怎么持续迭代？最小投入怎么做到
问题五 Agent 测试和传统测试，差别真的那么大吗
这篇按"从掏钱到上线"的顺序答一遍。前面先加一章立论，因为它比五个问题本身更要紧。
一、先纠正一个顺序：别先选，先定义"能用"
客户开口第一句几乎都是"自建好还是买好"。这个问题问早了。
先看一组数字，感受一下现在的水温。
| | |
|---|
| | |
| 2065 亿美元（2027 年将达 3763 亿） | |
| 超过 40% | |
| 11% | |
| 171% | |
| | |
| | |
| | |
数据来源：Gartner IT Symposium/XPO 2025 及 2026 年追踪数据；Prefactor《Evaluating agent readiness for autonomous deployment》（2026.03）；MIT Project NANDA（2025.08）；S&P Global 2025 年企业 AI 调研。
11% 走到生产，40% 被取消，活下来的 ROI 是 171%。
这两组数字看着矛盾，其实是同一台筛选器的两面：活下来的项目都有共同特征，任务窄、责任人明确、治理在上线前就建好。
Gartner 把失败原因归成三类：成本失控、业务价值不清、风险治理不足。三件事里，没有一件是"模型不够强"。
Prefactor 那份就说得更直白：78% 的企业有 Agent 试点，能走到生产的不到 15%，问题多半不出在模型质量上，出在团队从头到尾没跟"什么叫做就绪"对齐过。上线这一步最后只能靠拍脑袋，或者靠老板的行政压力。
先定义"能用"，再谈选型
"能用"的标准不从模型能力清单里来，从人工基线里来。
别说"我要一个能处理工单的 Agent"。得换成："现在人工处理一张工单平均 8 分钟，准确率 96%，最常见的错是这两类，后果是客户要打第二通电话。我要 Agent 做到什么水平。"
这条基线得先立住，后面所有判断都拿它当参照。
人工基线四问
1. 这件事现在谁在做，一次要多久？
2. 做完的标准是什么，谁在检查？
3. 最常见的错误是哪几类，后果有多严重？
4. 出错之后怎么补救，成本多少？
这四个问题的答案凑起来，就是验收标准的第一版草稿。而且你会发现，把这件事做完，选型问题有一半自己就解了。你要买什么、要自建什么，全都取决于你要求它做到什么。
二、问题一｜自建还是买？先算三本账
这个问题被讨论了太多次，但大部分讨论都停在"自建有掌控力、采购上线快"这种谁也说服不了谁的话上。它其实是一道算术题加三句话。
第一本账：三年总拥有成本
数据来源：SearchUnify / FwdSlash 2026 年公开 TCO 模型汇总。口径为含构建、运维、维护的三年累计成本，不含机会成本；不同供应商测算方式有差异，仅用于量级参考。
规律很清楚：简单和中等复杂度，买的赢很多；到了企业级规模，差距从 12 倍急剧收窄到 6% 左右——但自建仍然略贵，这一档并没有反超。
换算成更好用的口径是一个会话量分界线：
· 每月 3000 次会话以下：买的在每一份公开 TCO 模型上都赢。订阅费 $20 到 $500 一个月，而自建起步就是两万美元量级，根本收不回。
· 3000 到 8000 之间：这个区间里"怎么计费"比"买不买"更重要（按次结算通常比按席位划算）。
· 8000 以上：token 开销变成主要成本项，这时候"自己掌握计量表"才成为自建的真正理由。
第二本账：自建常被低估的五项
这五项是客户踩坑最集中的地方。构建费只是冰山一角——它通常只占三年总成本的 25% 到 35%，剩下 65% 到 75% 是 token、基础设施、运维和合规。
| |
|---|
| 集成适配：以为 CRM 接口能直接调，实际字段名不标准、鉴权方式特殊、限流规则还和高频调用冲突 | |
| 知识库清理：文档版本不一致、格式不统一、内容互相矛盾。检索到这种内容，Agent 就会一本正经地答错 | |
| 合规审查与审计更新：每次改 Agent 行为（加工具、接新数据源）都要重新过审 | $50K+/年；法务批准 Agent 访问客户数据通常要 6 周 |
| token 用量失控：Agent 一个任务要调 5 到 30 次模型，不是一次。高推理模型能把月成本推到基线的 3 倍 | Uber 2026 年 4 月就花完了全年 AI 预算 |
| 模型版本迁移 | |
数据来源：OOMeta《AI Agent TCO: 2026 Enterprise Cost Framework》、Neontri 2026 年 AI Agent 预算指南、InApps 2026 定价指南汇总。均为公开报价区间的中位量级。
三档走完，有一句话得说清楚：自建有了理由，不等于自建更便宜。真正的成本反超门槛，比想象中远得多——
· 按会话量算，纯经济性的交叉点大约在每年 100 万次会话（约合每月 8 万次）；每年 10 万次以下，买几乎总是对的。
· 按 token 算，对 GPT-5.6 Sol 这类高价 API 每月 4 到 5 亿就能打平；换成 DeepSeek V4-Flash 这种低价 API，要 57 亿以上。你对比的 API 越便宜，自建越难反超。
· 最容易漏掉的是人工这一项：同一份研究里，不计运维人力是每天 1000 万到 1200 万 token 打平；把 MLOps 人力算进去，门槛直接跳到每月 300 亿 token 量级。差的那一百倍不是算力，是工资。
所以对绝大多数企业来说，等成本反超不太现实。让自建站得住脚的，是下面三条线。
第三本账：三条分界线（比钱更要紧）
1. 这个流程是不是你的竞争力。是，就自建；不是，就买。按经验，80% 的 Agent 场景（客服、销售线索、内部知识问答）买现成的完全够用，真正值得自建的只有那 20% 的差异化环节。
2. 合规和数据驻留。金融、政务、医疗这类行业，"数据不出域"是硬约束，私有化部署或自建几乎没有替代方案。
3. 你养不养得起 AI 工程团队。这里要看的是 AI 工程能力。会写大模型 demo 的开发不顶用，中间还隔着工程化、评测和数据治理三道墙。
回到那句"买的能满足业务吗"
这个问题其实问反了。任何平台上手都能覆盖你 60% 到 80% 的需求，决策点在剩下的那 20% 到 40%。所以采购该干的活是缺口评估。一款一款对着功能清单打勾，那没什么用。
换个问法，问题就清楚了：剩下这部分，是平台路线图上已经有了，还是要找服务商定制，还是得你自己补？补它要多少钱、多久？平台的扩展点（插件、API、脚本层）够不够你补？
顺手提醒：怎么识别"Agent Washing"
Gartner 估过：市场上宣称自己有 Agentic AI 能力的厂商有数千家，真正在做东西的只有约 130 家。其余是换个名字——把聊天机器人和 RPA 重新包装成"自主智能体"。
两个问题基本能筛出来。第一，你们的系统自主做哪些决定？（如果回答是"它能理解你的问题并给出答案"，那是助手，不是 Agent。）第二，人在哪一步签核，出错怎么回滚？
能说出具体动作、具体签核点、具体回滚路径的，是真东西。只说"我们的模型很强大"的，是包装。
三、问题二｜怎么算"能用"？四道门
这是全文最实操的一章。下面这套流程大约 6 到 8 周，四道门，全过才允许进灰度。
为什么不直接上线？因为上线后才发现问题，代价落在回滚上，已经影响几千条客户记录的改动，得一条条退回去。六周看起来慢，但跟"上线后撤回"比，快得多。
门 1：动作清单和权限边界（约 1 周）
第一件事，把 Agent 能做的动作全部列出来：每个动作的输入、输出、副作用分别是什么。
做不到这一步，后面就不用谈了——你没法评估一个自己都描述不清的东西。这份清单同时是后面所有测试的覆盖率基线。
权限跟着动作走，按最小原则给，每个动作都要有回滚路径。这里有个特别容易混的点："它能做什么"和"它被授了什么权"是两件事，要分开写。一个只读的分析 Agent 和一个能授权付款的 Agent，风险完全不是一个量级，即使它们底层是同一个模型、同一批人做的。
门 2：失败模式清单（1–2 周）
只跑正常流程等于没测。得主动喂四类对抗输入：
· 模糊指令——"把那个东西处理一下"
· 缺上下文——缺关键字段、缺附件、指代不明
· 工具返回矛盾——两个系统给的答案不一致
· 超出范围——问它职责外的事，或者诱导它越权
这一门要记的是"它是怎么失败的"。通过率是给老板看的，失败模式才是给工程看的。
一个真实案例：自信地编
亚马逊的零售站在 2026 年 3 月一周内多次宕机，其中一次持续 6 小时。内部调查的结论是：一名工程师采纳了 AI Agent 基于过期内部文档生成的代码修改建议，Agent 先是编造出了并不存在的配置参数，工程师没有二次验证就让代码上线了。
事后亚马逊增加了一条强制流程：AI 辅助的变更必须由资深工程师复核。
这类"自信地编"是 Agent 最典型的失败模式——它不会报错，它会给你一个看起来完全合理的答案。只测正常路径，永远测不出这一条。
门 3：打分基线（1–2 周）
准备一份 300 条以上的真实历史案例，覆盖日常操作和已知的失败场景，逐条标注正确答案或评分细则。然后打两类分：质量分（任务完成度、步骤准确度、输出正确性）和风险分（高风险动作比例、升级频率、越界行为）。
这里有个必须强调的原则：按类别记分，别只看总分。
一个 Agent 总体 94% 听起来很棒，但如果它在"多实体边界场景"这一类上只有 40%，而你的真实业务里恰好有大量这类场景，那它就是不能上。总分漂亮，掩盖的正是你最需要看见的东西。
还有一条：阈值要业务方签字，不能工程师自己定。财务签成本上限，风控签安全阈值，业务运营负责对人工基线。为什么非要这样？因为工程师会系统性地高估技术上的优雅程度，同时低估对一线运营的扰动——这事跟专业不专业没关系，所处的位置不同，看到的东西自然不一样。
门 4：影子部署（2 周）
把它放进生产环境"旁听"：对真实流量给出建议，但不执行，由人执行。然后每天比对三件事——
· 一致率：Agent 的建议和人工实际做的，对得上多少
· 不一致的分类：对不上的那部分，是 Agent 错了，还是人工有历史习惯？
· 价值差：如果让它自动做，能省下多少人工时间
连续两周一致率稳定或在改善，才进灰度。如果一周好一周坏，那通常说明它对输入组合敏感，能力其实还没长出来——继续影子，别急着上。
一张按后果分级的授权表
Gartner 有个观察我特别认同：企业治理 Agent 时容易走两个极端——要么锁死到毫无用处，要么给出它还没挣到的权限。两边都活不过生产。
正确的做法是按后果分级，别对所有 Agent 套同一套策略：
参考来源：Gartner 2026 年 5 月关于 AI Agent 分级治理的研究说明；Shadow 2026 年企业采购评分框架中的"按后果授权"模型。
落到实操就一句话：定自治程度之前，先问"做错了谁承担"。承担得起就自动化，承担不起就留签核点。
一张行业基准指标表（可以直接拿去当草稿）
下面这些是各类流程在公开实践里跑出来的经验区间。这些数字算不上国家标准，用处是给你一个校准的锚点：
数据来源：RTS Labs《Agentic AI Evaluation Metrics》（2026）公开的企业 Agent 基线区间汇总。
用法是双向自检：你的目标如果定得比这个低，先问自己为什么；定得比这个高，先问人工基线做不做得到。
一个反直觉的点：升级率不是越低越好
从不升级给人的印象是"它全能"，但真实含义通常是没有校准——该叫人的时候它没叫，在自己拿不准的地方继续硬答。
升级率低不低不重要，关键是升对了多少：真不确定的时候升了，动作不可逆的时候升了，风险超过阈值的时候升了。这才叫校准。
四、问题三｜红线是通用的，业务是自己的
"安全红线都是固定的，那跟我们自己的业务到底怎么结合？"这个问题问到点子上了。答案藏在一个区分里：你手上其实有两套标准，它们该用不同的方法做。
混着来会出两种浪费：指望第三方替你决定能不能上线（它不知道你的业务标准），或者从零自己造内容安全题（这块公共知识已经很成熟，没必要重造）。
拿一个具体问题举例："客服 Agent 能不能查客户订单历史，算不算越权？"——同行业不同公司答案不一样，取决于你的数据分级、客户授权范围、以及这个动作有没有留痕。这问题没有通用答案，得回到你自己的业务定义里去找。
业务能力这块，用最小投入怎么做
核心方法就一句话：从人工基线里抄答案。
你的 golden set（黄金测试集）有三个来源，成本从低到高：
1. 历史真实工单和处理记录——价值最高，因为分布是真实的，不用假设用户会怎么问
2. 已知的失败案例——客户投诉、返工记录、事故报告。这些天然就是最该测的边界
3. 业务专家现场造题——补覆盖盲区，成本最高，所以放最后
有个小技巧特别实用：同一类问题，调出三份答案——老师傅怎么答、新人怎么答、哪一种被客户投诉了。这三份就构成了"优秀/及格/不合格"的评分参照，比你从零写评分细则快得多，也更贴近业务真实标准。
所以别一上来问"Agent 答得对不对"。先看人是怎么做的，标准答案本来就在记录里。
怎么做到不占业务时间：影子模式
这是回答"不过多占用业务时间成本"的关键动作。做法在第三章讲过——Agent 在生产环境旁听真实流量、给建议不执行。落到"省时间"这件事上，它有三个直接好处：
· 不用专门组织业务人员抽时间做评测。评测嵌在日常工作里，没人需要额外加班出题
· 看的是真实分布，会议室里造的题不作数。测出来的结论能直接对上现实
· 顺手算出 ROI——"如果让它自动做，能省多少人工小时"，这个数天然就有了
业务方每周要花的时间，就是看两张清单：判断不一致的清单，和升级给人处理的清单。加起来一小时，够撑起一轮迭代。
垂类业务怎么和 AI 结合：一句实在话
别指望通用 Agent 学会你的业务。正确做法是把业务知识做成它能查的东西——知识库、规则、工具接口，别指望它自己记住。
西门子那个案例值得细看：他们每周收到约 3000 条销售线索，来自全球 7 个业务部门，靠人工筛不现实。上线 Agent 时做的一个关键决策是——从生成式 AI 的编排方式，切换到确定性的 Agent Script。
原因是 LLM 编排偶尔会跳过关键的资格审核问题。在销售流程里，可靠性比灵活性重要。
这就是垂类业务的正确姿势：必须稳定的判断写成规则，需要理解的部分留给模型。哪部分归哪边，恰恰得靠评测来定——测出来它在哪类判断上不稳定，那类就该转成规则。评审和规则，是一来一回互相长出来的。
五、问题四｜上线不是终点，评测是张会过期的照片
很多人把验收当成项目终点。但 Agent 有个特点：今天测过的东西，下个月不一定还成立。
三个会悄悄让它变差的东西
1. 模型版本更新。供应商 6 月发了个新 checkpoint，你的 7 月 Agent 可能就悄悄退化了。不重测，这件事只能从客户投诉里知道。
2. 工具接口变更。字段名改了、token 过期了、限流规则变了。任何一个都能让你的成功率先掉一截。
3. 输入分布漂移。业务变了、活动上了、季节换了，进来的问题和你测的时候不是同一批。
这三件事都不需要你改任何代码。所以"评测通过一次"这种状态根本不存在，只有"持续评测"。
节奏怎么定
| |
|---|
| 上线后前 3 个月 | 每周看 4 个数：任务成功率、决策准确率、升级率、误报与漏报率 |
| 前 6 个月 | 每月跑一次内部基准，对比上线时的基线；掉超 3 个百分点就触发复查 |
| 6 个月之后 | |
| 复审周期 | 高风险流程按季度、低风险按半年；任何模型或工具变更，立即触发 |
为什么前三个月要按周看？因为这是退化风险最高的时期——真实流量的分布会教给你一批测试环境里没出现过的情况。
一个容易忽略的成本：人的那一边
Agent 部署失败，有时候技术上一丝毛病没有，问题出在组织上。两种典型：评审员被误报淹没，看到麻木了；或者更糟——变成橡皮图章，什么都点通过。
盯两个数就够：标记精确率（Agent 升级上来的，有多少真的需要人看）和抽检错误率（已放行的结果里，抽样发现多少是错的）。
如果标记精确率掉到 60% 以下，或者抽检发现已放行结果的错误率超过 2%——先停下来扩展，去重训 Agent 或者重设流程。不然你扩大的是一条没人把关的通道。
什么时候该杀掉它
· 两个完整的迭代周期之后还过不了人工基线 → 杀
· 失败都压在核心类别上，边缘类别反而干净 → 杀
八周诚实评测之后砍掉一个项目，很便宜。十八个月沉没成本之后再砍，很贵。
六、问题五｜和传统测试，差别真的那么大吗
大。但它算不上"更难的测试"，它压根就是另一种测试。
| | |
|---|
| 输出行为 | | |
| 断言方式 | | 写不出精确断言，改用质量指标 + n 次运行的成功率 |
| 输入空间 | | 自然语言，无限。靠合成数据 + 代表性抽样 + 红队 |
| 质量判定 | | |
| 失败定位 | | 跨步骤因果链：第 3 步检索差 → 第 5 步误解工具结果 → 第 8 步编出结论 |
| 回归触发 | | |
| 谁来判 | | |
| 性能指标 | | |
还有一层更本质的差别：传统测试问"代码做了什么"，Agent 测试还得问"它是个什么样的家伙"——会不会选错工具？守不守权限边界？记忆干不干净？失败之后能不能恢复？会不会中途跑偏？
这些是行为属性，不是输出属性。输出对，行为不对，一样是失败。
心智模型得换一个：把功能测试换成性能测试
做性能测试的时候，你不会问"这个请求成功了吗"，你会问"一千个并发请求下，这个系统表现如何"。你要找的是统计规律，单次成不成说明不了什么。
测 Agent 是一回事：你的断言要变成指标，你的用例要变成分布。
一句最省事的对比：传统软件测试问"它能不能工作"，Agent 测试问"它能不能工作、好不好、安不安全、还能不能一直这样"。
给做测试的同行一句实在话：不用推翻现有体系。接口、权限、边界、状态这些确定性部分继续用老办法测，而且得测得更严——因为 Agent 会主动去调它们。新增的工作量集中在另外三块：语义质量、执行轨迹、行为特征。战场只是变大了，没有作废。
七、最小投入：三周能做完什么
如果现在就要动，但又不能占业务太多时间，可以从这个三周最小版本开始。
| | |
|---|
| 第 1 周 | 做人工基线四问 + 收集 50 到 100 条真实历史案例 | |
| 第 2 周 | 定三个数（成功率、升级率、成本上限），跑一轮，按类别看分 | |
| 第 3 周 | | |
要说清楚的是，这三周严格说算不上上线验收，它回答的是"值不值得进下一阶段"的判断。它的价值在于用三周时间换一个明确的继续或叫停，比花半年做一个谁都不敢用的东西划算得多。
回到最开始那句。
客户问我 Agent 怎么选，我现在给的建议都是：先别选，先把"什么样算能用"写清楚。
选型是采购动作，验收是业务动作。顺序反了，钱花出去就很难证明花对了。Gartner 那 40% 里，有相当一部分栽在别的地方，从第一天起，就没人定义过成功长什么样。
所以评测这件事的价值，不在最后给出一个分数，在于让这个分数能被人签字。
附：15 项 Checklist
选型之前
1. 写了人工基线——这件事谁在做、多久做完、什么标准、常见错哪几类
2. 按后果给动作分了级，标出哪些必须人批
3. 算过三年 TCO，包含那五项隐藏成本
4. 分清了哪部分是竞争力（该自建）、哪部分够用就行（该买）
5. 用"自主做哪些决定 + 人在哪签核"筛过一遍厂商
验收的时候
6. 枚举了全部动作和副作用，"能做什么"与"被授了什么权"分开写
7. 权限按最小原则给，每个动作有回滚路径
8. 失败模式清单覆盖了四类对抗输入
9. 测试集 300 条以上真实案例，按类别记分而不只看总分
10. 阈值由业务方签字，工程师说了不算
11. 影子部署跑满两周，一致率稳定或在改善
12. 安全项（提示注入、越权、数据泄露、内容）单独跑过一轮
上线之后
13. 上线后 3 个月每周看四个数，异常清单有人签字
14. 模型或工具变更立即触发重测
15. 定了复审周期和弃用标准，并且事先跟业务方对齐过
如果你正在做 Agent 落地，或者刚被老板问"这个买了到底行不行"，欢迎在评论区说说卡在哪一步——选型、验收、还是上线之后不敢放权
