为什么智能体项目失败率如此之高？答案其实很直接：许多人依然沿用传统软件的思维模式来构建智能体。

在过去一段时间里，行业深度观察了数十个Agent实践案例。结果让人不得不正视一个现实：智能体项目的失败率，远高于传统软件项目。

大多数项目无法落地或最终折戟，核心问题在于思路没有转变——仍然套用传统软件开发的框架。今天，我想分享一些经验与思考。

其实，早在8个月前（在AI领域这已经是很久以前了），有一篇文章非常值得推荐，它清晰定义了Agent与Workflow的区别，用简明扼要的图文解释了围绕大模型构建Agent的多种流程。更重要的是，它暗藏了一个被许多人忽视的预见：Agent的业务架构，应该比传统软件简单得多。

这一点很早就被捕捉到，并在实践中严格贯彻。许多发现也建立在这个基础上。当然，需要坦诚的是，认知局限在某种特有的品位和偏好上。

我们是专业领域的行家，而不是软件开发者，所以并不热衷于打造Manus那种通用Agent。更值得迷恋的是，为某个特定任务——比如写一篇无需修改就能发表的期刊论文，或者为体检报告出具专家级诊断，或者把嘈杂的会议录音整理成可提交法庭的卷宗——打造一个真正可用的Agent。然后，一边喝茶，一边看它以过硬的交付质量和极低的失败率，稳定地批量完成任务。

换句话说，我们不造万能料理机，专门造能焖出香喷喷米饭的电饭煲。

目标变清晰后，对Agent开发的重心也完全不同了。你会发现，虽然AI已经渗透了生活的方方面面，但面对具体的工作任务时，表现往往令人摇头。就算它的能力达到博士级别，你也不敢让它直接上岗。

那么，“胜任工作”到底该如何评估？

传统软件工程师没有能力独立进行这项评估——他们拿到需求就开始按流程拆解：需求、设计、前端、后端……结果呢？大量专用Agent，要么只会看似体面的对话，要么在最终任务上频频出错。业务方最终还得自己上手。这些Agent，除了发布会时演示一下，大多数时间都在吃灰。

软件开发和Agent开发的根本区别在哪里？

前者靠硬编码驱动，能力边界是确定的，只要符合逻辑，代码就能实现。后者靠大模型（LLM）驱动，能力边界是模糊的——本质上是概率预测器。所以，一个Agent需求，即便投入资源，也可能无法实现，因为你不能百分百控制LLM。

因此，Agent开发绝不能走“需求提出→确认→原型→设计→前后端→测试上线”这条确定性老路。

那么，如果你想为工作中某个任务造一个智能体，让它替你干活儿，该怎么办？在把需求甩给开发团队之前，建议你先做一件事：“智能体能力基准测试”。

什么是智能体能力基准测试？简单说，就是在传统开发流程中，把“提出需求”和“确认需求”两个环节，改造成一个“能力基准测试”环节。流程中有了这一步，才能进入标准软件开发。

这个环节的核心目的，是校准和判断：“大模型能不能按标准完成需求？”

请注意：不是所有需求都能让大模型完成。完不成的，就不该进入开发流程——要么修改需求去适应模型能力，要么等模型升级。智能体开发，本质是在找“业务需求”和“大模型能力”之间的最大公约数。而这个找最大公约数的过程，就是“智能体能力基准测试”。

很多失败案例，恰恰是没做完这个测试，就匆忙进入开发，最后发现Agent根本无法胜任，两头浪费。

“智能体能力基准测试”由三个环节构成：

一、基准任务要求提出

在这个环节，Agent的用户要明确任务需求，详细描述输入和输出，并给出至少10个以上的输入示例。比如，让AI帮忙写周报。在写任何代码前，先明确输入的代码提交记录，输出的周报格式、术语、人名、字数、板块等。至少10个示例，确保任务适用范围足够广。

二、基准样例确认

这个环节不断调试大模型或智能体的能力，让它胜任任务，并形成未来评估用的基准。调试方法包括：提示词工程、换模型、增加Agentic流程、RAG、SFT等等。没有SOP，全靠算法工程师的经验——有点像“炼丹”。过程中根据输入示例多次生成输出，交给需求方确认反馈，直到双方都满意。评估标准可以从六个维度看：可信性（有无幻觉）、准确性（是否理解用户意图）、全面性（是否覆盖需求范围）、专业性（术语使用）、规范性（格式体例）、响应速度（首字符输出时间）。如果多轮后仍无法产生满意样例，那么这个方向就该放弃了。如果满意，该样例就作为基准样例备用。

以写周报为例，选一周代码，给模型写一段精准提示词，看看生成质量。如果满意，炼丹成功。但现实往往不简单——格式不对、内容跑偏、协作者名字引用不对……你需要不断加提示词、加人名列表。终于，你觉得周报像样了，基准样例就完成了。

三、智能体能力测试

这个环节的目的，是通过规模化测试判断智能体的能力是否稳定、可规模化。操作是：用户提供大约50~100个输入示例，调用调试好的智能体产出输出，然后交给专家组盲审。盲审是对比输出与基准样例在可信性、准确性、全面性等方面的偏差度，分三档：明显偏差、可接受偏差、无偏差。当接受度超过95%时，就可以认为智能体具备了稳定且符合需求的能力，才进入软件开发流程。没通过？继续优化或放弃。

以周报为例，你在提示词层面输出稳定后，调出过去10周的代码用同样的提示词生成。很快你会发现结果不可控——有几周写得好，有几周出错。于是你添加更多信息到提示词，但提示词太长模型注意力又漂移。你开始尝试RAG引用外部信息，控制长度，又把周报拆成三段分别执行再拼合。甚至考虑SFT一个小模型专门解决术语引用问题。最终，输出稳定了，通过了你的盲测。但如果推广到全公司几千个程序员呢？它能不能扛住？

以上是Agent开发有别于传统软件的特有流程。在这些环节没完成之前，建议一行软件代码都不要写。

以上写周报的例子是内部真实案例，但实际项目比这复杂得多——这也让人对人类“工作”本身生出更多敬畏。

虽然智能体能力测试方法论不复杂，但在现实中推力巨大。摩擦力不光是理念问题，更多来自人才技能与AI时代需求的结构性错配。这是生产力与生产关系的矛盾。

把LLM调教成能高质量完成一个任务，需要对任务本身、LLM的能力边界、以及提升LLM能力的技术体系都特别熟悉。而这个工作，没有现成的人才供给。很难用过去的软件工程角色定义“谁该负责智能体能力基准测试”——它既需要业务理解抽象，又需要代码工作。

现实中常看到：产品经理觉得该程序员做，程序员觉得是业务问题，他只管实现。来回拉扯，失败项目就诞生了。

在Agent开发时代，需要怎样的人才？这个话题值得另文探讨。

总结

工作，是任务的集合。而任务本身，定义工作。

相比抽象的工作，更值得看重的是每个具体任务的质量。帮AI把一个任务做得更好，这事很迷人。现阶段，更倾向于“一个任务一个智能体”的模式。

如果你希望打造一个能真正高质量交付工作的智能体，推荐参考智能体能力基准测试。限于保密，这次没分享具体案例，后续期待有机会深入交流。