大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



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

其中，一个主要原因是许多团队仍然在用传统软件开发的思路来构建智能体。这导致了大量项目无法真正落地。因此，我们想分享一些在实践中的经验和核心思考。

在探讨如何打造一个有效的智能体时，虽然已经过去了8个月（这在AI领域已经是一段相当长的时间了），但我们依然非常推荐 Anthropic 的这篇文章：Building Effective AI Agents。

这篇文章清晰地定义了 Agent 和 Workflow 的概念区别，并以简明的图文解释了围绕大语言模型构建智能体的多种流程。更重要的是，它隐含了一个被许多读者忽视的预言性观点：智能体的业务架构复杂度，应当远低于传统软件。

我们很早就意识到了这一点，并在构建各种智能体时严格贯彻了这个思想。许多发现也基于此产生。不过在分享之前，必须提及我们的认知局限：源于我们对于智能体的特定品位和偏好。

我们是专业领域（非软件工程）的专家，因此并不沉迷于打造类似“全能助手”这样的通用智能体。我们更偏好为某一个特定任务打造真正可用的专用智能体——比如写一篇达到发表水平的期刊论文，或针对体检报告给出专家级诊断，或将复杂的多人对话总结成法庭卷宗。然后，我们能一边喝茶，一边看着它以可信的交付质量和极低的失败率，稳定、批量地完成任务。

换句话说，我们不太热衷于制造“万能料理机”，而是专注于打造能把米饭做得香喷喷的“电饭煲”。

设定了这样的目标后，对智能体开发重心的认知就会发生变化。我们会发现，虽然AI已深入生活，但它们在涉及专业、特定工作任务上的表现，往往不尽如人意。即便AI具备了博士或专家级的知识水平，我们也无法想象它能未经“训练”就直接上岗、立刻胜任。

那么，如何评估一个智能体能否“胜任工作”呢？

传统软件开发工程师并不擅长也没有能力独立完成这种评估。他们通常拿到需求后，就按部就班地进入产品、设计、前后端开发等环节。结果就是，我们看到了大量专用智能体，要么只能进行看似像模像样的对话，要么在处理最终任务时表现不佳。业务人员最终还是得亲力亲为，智能体则除了演示时亮相，大部分时间都被束之高阁。

这背后的本质不同在于：

• 软件开发的核心引擎是硬编码，其能力边界是确定的。只要需求符合逻辑，在成本合理的前提下，开发者通过编码就有近乎100%的概率实现它。
• 智能体开发的核心引擎是LLM（大语言模型），其能力边界是模糊的（本质是概率预测器）。因此，即使有充分的资源和成本，也无法保证一个由客户提出的智能体需求一定能被实现，因为开发者无法像控制代码那样百分百地控制LLM。

所以，在智能体开发中，绝不能照搬“需求提出、确认、设计、开发、测试”这套以确定性为核心的传统软件流程。

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

简单来说，就是在传统流程中，用“智能体能力基准测试”环节取代“需求提出与确认”环节。只有通过这个测试，项目才能进入后续的标准软件开发流程。这个环节的核心目的，是校准和判断 “大模型是否能够按照某个既定标准完成需求”。

需要注意的是：并非所有需求都能被当前的大模型完成。 对于那些无法完成的，就不应进入开发流程，而是应该修改需求以适应模型能力，或者暂时搁置计划，等待模型能力升级。简而言之，智能体开发是一个求解“业务需求”与“大模型能力”之间最大公约数的过程，这个过程就是“智能体能力基准测试”。

在许多失败的智能体项目中，团队往往尚未完成这个基准测试，就匆忙开始编码，最终发现智能体根本无法满足实际业务需求，导致甲方乙方都产生巨大浪费。

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

一、基准任务要求提出

在这个环节，智能体的最终用户需要提出明确的任务需求。任务必须详细描述输入和输出，并提供至少10个以上的输入示例。

举个例子：
某程序员希望AI帮他撰写周报。那么，在写任何代码之前，他必须先明确“写周报”任务的输入和输出。输入可能是每周所有的代码提交记录，输出则是多份他自己对质量都满意的周报示例。细节需包括：具体格式、使用哪些专业术语、是否涉及同事姓名、字数规模、内容板块划分等。这样的示例需要至少10份以上，以确保任务定义的广泛性。

二、基准样例确认

这个环节的目标是通过调试，让大模型或智能体原型能够胜任用户的任务，并产出一个可用于未来评估的“基准样例”。

调试方法包括但不限于：提示词工程、切换不同模型对比、增加智能体流程（Agentic Workflow）、采用多种RAG技术、进行监督微调（SFT）等。这个过程没有标准作业程序（SOP），很大程度上依赖于算法工程师的个人经验和能力（某种意义上的“炼丹”）。

调试中，工程师会根据输入的示例，多次生成输出结果，提交给任务需求方确认和讨论，然后回炉调整，直到双方对输出结果均感满意。达成满意的标准可以从以下六个维度评估：

• 可信性（有无幻觉）
• 准确性（是否充分理解和反映了用户的意图）
• 全面性（是否涵盖了需求答案的所有必要范围）
• 专业性（是否正确使用了专业术语等）
• 规范性（是否遵循了要求的标准格式或体例）
• 响应速度（生成第一个token的延迟时间）

如果经过多轮尝试仍无法产出令所有人满意的基准样例，就应该放弃这个智能体方向。如果满意，则将这个样例作为后续评估的基准。

继续以程序员写周报为例：
在这个环节，你需要选取某一周的代码，交给大模型，并设计一段相对精准的提示词，指导它如何撰写周报，然后评估LLM输出的质量。
如果质量满足你的标准（可用上述六个维度评估），那么“炼丹”就顺利完成了。
但现实中往往没这么简单。你可能会发现它无法控制好格式或内容重点，于是需要不断补充和修改提示词。或者发现它无法正确引用协作者的名字，这就需要你把协作者列表等信息也加入提示词。
最终，当LLM写出的周报让你觉得“像样了”，这个环节才算完成，你获得了一份可参考的基准样例。

三、智能体能力测试

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

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

再次以写周报任务为例：
在第二个环节，你的提示词工程已经可以输出一份让你满意的周报了。于是，你调出过去10周的代码，用同样的提示词交给LLM处理。
很快，你可能会发现结果并不完全可控。在这10份输出中，有几周的周报可能有问题，有些内容无关紧要，有些格式错乱。
于是你尝试在提示词中加入更多信息来控制输出，但很快又发现提示词变得冗长，导致模型注意力分散。接着，你可能会尝试用RAG技术来引入准确的外部信息，以缩短提示词。随后又发现LLM无法稳定控制段落结构，于是决定把周报拆分成三段，每段分别生成后再拼接。
你甚至可能考虑是否要SFT一个小模型来解决内部术语引用的问题。无论如何，经过一系列调整，你终于让智能体的输出稳定下来，并通过了你个人（作为专家）的盲测。那么，如果你想把这项功能推广到全公司呢？这个智能体的能力，能否经受住几千名程序员的真实使用考验？

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

文中的写周报智能体是我们内部的一个真实案例。但现实中的案例往往比这复杂得多，这也让我们对人类“工作”本身的哲学意义产生了更多敬畏。

虽然“智能体能力基准测试”的方法论并不复杂，但在实际推动中仍会遇到巨大阻力。这种阻力不完全来自理念，更多源于人才技能构成与AI时代需求之间的结构性不匹配——一组生产力和生产关系之间的矛盾。

要想将LLM“调教”成能高质量完成特定任务的状态，需要对任务本身、LLM的能力边界、以及提升LLM能力的技术体系（如提示词工程、RAG、SFT等）都非常熟悉。而目前，市场上并没有唾手可得的现成人才供给。我们很难用过去的软件工程角色（如产品经理、后端开发）来明确定义到底该由谁来负责“智能体能力基准测试”这项工作，因为它同时需要业务理解抽象能力和相当程度的算法与代码能力。

现实中，我们经常遇到这样的困局：产品经理认为这该由算法工程师或程序员完成，而后者则认为这是业务问题，自己只负责实现。在不同角色的拉扯之间，一个个失败的智能体项目便诞生了。

所以，在智能体开发时代，我们究竟需要怎样的人才？这又是一个值得深入讨论的话题了。

工作是任务的集合，而任务本身则定义了工作。相比抽象的工作概念，我们更重视每一个具体任务的完成质量。帮助AI把单个任务执行得更好，对我们而言是极具吸引力的事。因此，在当前阶段，我们更倾向于采纳 “一个任务，一个智能体” 的模式。

如果你希望打造或正在打造一个能够高质量交付工作的智能体，我们推荐你参考上述的“智能体能力基准测试”流程。限于保密要求，本次无法分享具体的测试案例细节，希望后续能在云栈社区与大家进行更深入的探讨与交流。