1. 智能体项目失败率远高于传统软件项目，主要原因是开发思路未跳出传统软件开发局限。
2. 智能体的业务架构复杂度应远低于传统软件，开发者需转变对开发重心的认知。
3. 智能体开发与传统软件开发本质不同：传统软件开发核心是硬编码，能力边界确定，可 100% 实现符合逻辑的需求；智能体开发核心是 LLM，能力边界模糊，开发者无法百分百控制，并非所有需求都能实现。
4. 智能体开发应先进行 “智能体能力基准测试”，包括基准任务要求提出、基准样例确认、智能体能力测试三个环节，完成后才可进入标准软件开发流程，此过程是求解 “业务需求” 和 “大模型能力” 最大公约数的过程。
5. 现实中智能体开发面临人才技能与 AI 时代需求不匹配的问题，相关分工角色不明确。
6. 现阶段更适合采纳 “一个任务一个智能体” 的模式，注重具体任务的质量。

最近参与了大量Agent开发，于是想说……

在过去一段时间，我们高密度地参与和观察了数十个agent的实践案例。从效果来说，智能体项目失败比例远远高于传统软件项目。

大部分智能体项目无法落地或最终失败的主要原因之一，是在整个工作思路没有跳出传统软件开发的局限。因此，我们想分享一些自己的经验和思考。

关于如何打造一个智能体这个话题，虽然过去了8个月（在AI领域已经是很久的一段时间了），但我们仍然非常推荐这篇文章。

Building Effective AI Agents

Anthropic

这篇文章清晰地定义了agent和workflow的概念区别，并且以非常简明扼要的图文解释了围绕LLM来构建agent的多种流程。更重要的是，它隐含了一个被很多读者都忽视的预言性概念：

agent的业务架构的复杂度应当是远远低于传统软件的。

我们很早就察觉到了这一点，并在打造各种agent的时候严格地贯彻了这个思想。很多发现也都是在这个基础上产生。在分享这些发现之前，必须提及的一点：我们的认知局限在我们对agent的特有品位和偏好上。

我们是专业领域（非软件）的专家，因此并不沉迷于打造类似manus这样的通用agent，或者某些功能强大且广泛的agent。我们喜欢的是为某一个特定任务（比如写一篇不需要修改也真正达到发表水平的期刊论文，或者能够针对一个体检报告给出专家级别的诊断，或者把一段多人复杂嘈杂的对话总结成可以提交法庭的卷宗报告等等）打造一个真正可用的agent。然后一边喝茶，一边看着它以可信的交付质量和极低的失败率稳定批量地完成任务。

换句话说，我们不太喜欢去造那种万能料理机，相反，我们喜欢打造能做出香喷喷米饭的电饭煲。

当设定了这样的目标，对于agent开发工作的重心认知就会发生变化。我们会发现，虽然AI已经深入了我们的生活，但它们在涉及工作、或者某个专业的特定任务上的表现，几乎都不能让人满意。即使AI的能力达到了博士、或者是专家水平，我们也没有办法想象它可以未经训练地直接进入真实的工作，立刻就能胜任。

那么，“胜任工作”这件事，如何评估呢？

软件开发工程师们是不擅长也没有能力独立去完成这个评估的，往往拿到需求，就开始按照需求、产品、设计、前后端等环节进行开发了。因此我们看到了大量的专用agent，要么只能进行看似有模有样的对话，要么就是在处理最终任务时表现不佳，业务人员最终还是自己亲自上阵，完成工作交付。最后这些agent除了在面对公关关节时演示一下，大部分时间都束之高阁，无人使用。