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

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

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

Building Effective AI Agents

Anthropic

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

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

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

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

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

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

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

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

软件开发和agent开发，两者的本质不同在于：

软件开发中，驱动软件进行工作的核心引擎是硬编码，硬编码的能力边界是确定的，只要符合逻辑的需求，硬编码都能够实现。所以核心工作是产品需求确认，在确认后，在成本合理的情况下，开发者通过硬编码，就有100%的概率可实现。

但在agent开发中，驱动agent进行工作的核心是LLM，LLM的能力边界是模糊的（本质是概率预测器），就像人一样。因此，对于一个由客户提出的agent需求，即使有充分的资源和成本，但也不一定能够被开发实现。因为不同于确定性的代码，开发者无法百分百地控制LLM。

所以，在agent开发中，是不能采用“需求提出、需求确认、原型设计、交互设计、前后端开发、测试上线”这种以确定性作为核心思想的传统软件流程的。

那么，假如你想为你工作中的某个任务打造一个智能体，让它替你工作，你应该怎么办呢？在你把需求交给开发团队之前，我推荐你先做一个：“智能体能力基准测试”。

智能体能力基准测试是什么？

简单来说，就是在传统软件开发流程中，把需求和提出和需求确认环节，改造成一个“智能体能力基准测试”的流程环节。只有完成了这个流程环节，才可以进入到软件开发的标准流程环节中。而这个环节的主要目的，就是校准和判断“大模型是否能按照某个标准完成需求”。

需要注意的是：并不是所有的需求都可以被大模型完成，而不能完成的，就不应当到软件开发流程中，而是修改需求，以适应大模型的能力；或者暂时搁置这个计划，以等待大模型的能力升级。简单来说，智能体开发的过程，是一个求解“业务需求”和“大模型能力”之间最大公约数的过程。而这个过程，就是“智能体能力基准测试”。

但在很多失败的智能体开发例子中，往往都是尚未完成“智能体能力基准测试”，就匆忙开始软件开发的流程，最后发现智能体根本无法满足用户需求，也无法胜任实际业务，整个工作无论是甲方还是乙方，都产生了巨大的浪费。

我们的“智能体能力基准测试”是由以下三个环节构成的：

一，基准任务要求提出

在这个环节里，agent的用户应当提出明确的任务需求，该任务需要详细地描述输入和输出，并给出至少10个以上的输入示例。

举个例子：

某个程序员希望AI帮他完成周报撰写工作。那么，在你写任何代码之前，你要先明确“写周报”这个任务的的输入和输出。输入可以是你每周的所有提交代码。而输出则是多份你对于质量都满意的周报示例。细节包括，具体格式、专业术语、是否涉及其他同事的人名、具体字数规模，内容板块等等。而这种示例需要至少10个以上，以确保任务适应的广泛性。

二，基准样例确认

这个环节是不断调试大模型或智能体能力，使之能够胜任用户的任务，并形成未来评估使用的基准。

调试的方法包括但不限于提示词工程、换模型对比、增加agentic流程、多种RAG、SFT等等。这个调试环节没有SOP，更多依赖的是具体执行工作的这个算法工程师的个人经验和能力（某种意义上的“炼丹”）。调试过程中，工程师会根据输入示例，多次生成输出结果，提交给任务需求方确认和讨论，再回炉重炼，直到双方对于输出结果均满意为止。达成满意的标准可以从这六个方面进行分解评估：

• 可信性（有无幻觉）

• 准确性（是否充分理解和反映了用户的意图）

• 全面性（是否涵盖了需求答案的所有范围）

• 专业性（是否使用了专业术语等）

• 规范性（是否使用了规定要求的标准格式或体例）

• 响应速度（第一个token输出的反应时间）

假如多轮之后，仍然无法产生令所有人满意的基准测试样例，应当放弃这个智能体方向。假如都对该样例满意，则将把这个样例作为基准样例使用。

以程序员写周报任务为例。

在这个环节里，你需要选一周代码，交给大模型，写一段相对精准的提示词，告诉它要如何如何写周报，然后看一下LLM写出来的质量如何。

如果质量满足你的标准（可以用以上的六个方面来评估），那么这个炼丹工作就顺利地完成了。

但现实中往往并不那么简单。很快，你会发现它没有办法很好地控制格式，或者内容。你需要不断地添加提示词。或者你会发现他没有办法把协作者的名字引用正确，你需要把协作者名称列表这些信息也添加到提示词里。

终于，你觉得LLM写出的周报终于像点样子了。这个流程完成了，你获得了一份可以参考的基准样例。

三，智能体能力测试

这个环节的目的通过规模化测试，以确定智能体的能力是否稳定且可规模化。

该环节的具体操作是：由用户提供约更大规模的（50～100个）的输入示例，然后调用在环节二调试完成的智能体，产出输出示例。并把这些输出示例，交给专家组进行盲审。盲审的方式是对比这些输出示例和测试样例在“可信性、准确性、全面性”等方面的偏差度，并给这些输出示例进行偏差度评分，一般会设置为三档（与基准样例有明显偏差，与基准样例的偏差可接受，与基准样例无偏差）。当接受度超过95%时，即可认为该智能体具有了稳定的符合用户需求的能力，才可以进入到智能体的软件开发流程；假如不通过，则需要继续优化，直到通过为止，或者放弃这个智能体方向。

以程序员写周报任务为例。

你在第二个环节的提示词工程已经可以输出你想要的周报了。于是你调出了过去10周的代码，用刚才设计出的提示词工程给到LLM。

很快，你会发现结果并不是那么可控，在10周的输出中，你会发现有几周的周报写的有问题。有些无法很好地控制结果，有些无关的内容也出现了。

于是你决定把更多的信息加入提示词，但很快，你发现提示词太长，模型的注意力无法聚焦了。然后你开始尝试用RAG来引用准确的外部信息，以控制提示词的长度。然后你发现LLM无法稳定地控制段落了，于是你决定把周报拆成三段，每段分别执行一次，然后再做拼合。

你甚至会考虑要不要SFT一个小模型，让它专门来帮你解决内部术语引用正确的问题。但不管怎样，你终于让这个智能体的输出稳定了下来，通过了你作为个人专家的盲测。那么，假如你想把这个功能推广到全公司呢？这个智能体的能力，能否经受住全公司的几千名程序员的实测？

以上，是智能体开发有别于传统软件开发的特有流程。在以上环节未能完成之前，我们强烈建议不要多写任何一行软件工程侧的代码。

以上写周报agent的例子，是我们内部的一个真实案例。但现实中的案例比这个复杂得多（这也让我们重新对人类“工作”这件事本身的哲学意义生出了很多敬畏）。

虽然智能体能力测试这个方法论并不复杂。但在现实推动中，还是有着巨大的摩擦力。这个摩擦力并不完全来自于理念和思想，更多还是来自于人才技能构成和AI时代需求的结构性差异。一组生产力和生产关系之间的矛盾。

我们会看到，要想把LLM调教成可以高质量地完成一个任务，需要对任务本身、LLM的能力边界、以及提升LLM能力的技术体系都非常熟悉。而这个工作本身，并没有唾手可得的人才供给。我们很难用过去的软件工程分工角色来定义到底是需要谁来负责智能体能力基准测试工作。这各环节需要的技能包括了业务理解抽象和相当一部分程度代码工作。

在现实中，我们经常遇到的是：

产品经理认为这个工作应该程序员完成；而程序员则认为这是业务上的问题，它只负责实现。在不同角色的拉扯之间，一个个失败的agent项目就诞生了。

所以，在agent开发时代，我们又需要怎样的人才呢？这话题可以另外再去讨论和思考了。

总结

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

相比抽象的工作，我们更重视每一个具体的任务的质量。帮助AI把一个任务做得更好，对我们而言是非常有吸引力的一件事。所以这个阶段，我们更愿意采纳“一个任务一个智能体”的模式。

如果你希望打造或者正在打造一个能够真正高质量交付工作的智能体，推荐参考我们的智能体能力基准测试。限于保密问题，我们这次没有分享智能体能力基准测试的具体案例，后续希望有机会跟大家做深入分享。

作者：汤舸的笔记本