Prompt Evolution :迭代提示词设计让多智能体性能提升 30%

在多智能体系统中,提示词质量而非模型能力才是决定表现的关键。通过对主智能体、分析智能体、编码智能体和评判智能体提示词的系统性演进,工作流效率能够提升 30%。核心方法包括:明确智能体角色边界,将约束显式编码,将编码智能体从“作者”降格为“编译器”,以及依据失败模式驱动迭代。这一实践揭示了工业级 AI 工作流的本质。越确定性的任务越需要确定性的约束,而非期待模型自行领会意图。

发布于2026年5月9日 22:51
编辑小创
评论0
阅读31

提示词( Prompt )的质量,而非模型能力,才是决定多智能体系统表现的关键变量。这是软件工程师 Ajay Dhanysi 在重构一套超过 250 个 if-else 条件分支的 Apache Beam XML 解析器后得出的核心结论。通过对各智能体提示词的系统性演进,他测得整体工作流效率提升了约 30%,而底层模型在此过程中从未更换。

这套架构的基础是一个基于 Copilot 的多智能体工作流,包含主智能体( Main Agent )、分析智能体( Analysis Agent )、编码智能体( Coding Agent )以及若干评判智能体( Judge Agents )。早期版本已能基本运转,但问题持续浮现:分析智能体对 XML 字段的分组时常出现不一致。编码智能体会悄悄引入行为上的细微变化。评判智能体频繁标记出本不应进入该阶段的问题,导致多轮修正循环。这些问题的根源不在于模型推理能力不足,而在于提示词表述不清。

Ajay Dhanysi 将“提示词进化”( Prompt Evolution )定义为一种系统性工程实践,而非随机改写直到“感觉更好”。在他的方案中,提示词的演进遵循与生产代码相同的逻辑:依据观测到的失败模式迭代,依据可测量的指标验证,出现退步时回滚。

四个智能体的提示词各有侧重地经历了改造。主智能体原本在协调步骤时偶尔允许执行偏移,改造后明确禁止其生成代码,责任范围收窄为工作流执行的守门人,而非问题求解者,并加入了强制的步骤顺序规则。智能体之间的错误交接随之减少,重新执行的次数也明显缩短。

分析智能体的改造方向是将任务从“解读”变为“提取”。原始提示词允许智能体解释业务逻辑,改造后要求其只输出声明式结果,例如字段分组列表和规则映射,同时明令禁止给出任何优化建议。字段分组的一致性大幅提升,后续评判智能体标记的不匹配数量也显著下降。

获益最大的是编码智能体。原始提示词强调“代码整洁”却没有边界约束,本质上是在鼓励风格自由。演进后的版本把行为等价性( behavioral equivalence )设定为不可妥协的硬约束,明确禁止引入新的逻辑路径、快捷方式或抽象层,同时要求保留 Apache Beam 的执行特性,不得改变 XML 遍历语义。

对比前后的提示词版本,差异触目惊心。改造前的提示词只有三行:将给定的 Python 方法重构,让代码更整洁、更易维护,确保行为不变。听起来合理,实则给智能体留下了解释“整洁”含义的空间,也隐含着允许其进行优化尝试和逻辑重组的许可。改造后的提示词从角色定义开始,明确声明这是多智能体重构流水线中的编码智能体,任务是且仅是重构所提供的 Python 方法。随后列出硬约束:所有输入对应的输出值必须保持完全一致。不得引入新的逻辑路径、条件分支或快捷方式。不得优化、简化或重新解读业务规则。不得改变 XML 遍历语义。必须保留 Apache Beam 的执行特性。结构规则进一步要求严格依照分析智能体提供的字段分组进行重构,每个逻辑分组生成一个确定性函数,保留执行顺序和决策边界。输出格式被锁定为纯 Python 代码,不附任何解释性文字,注释仅在必须保留逻辑清晰度时才可使用。最后一条规则颇具工程哲学意味:如果存在任何歧义,停下来请求澄清,而不是猜测。

这个提示词的转变,本质上是将编码智能体从“作者”变成了“编译器”。首次通过率提升、评判智能体的拒绝次数减少,以及向最终批准输出的收敛速度加快,都是可直接观测的结果。 Ajay Dhanysi 估计,仅这一项改造就贡献了系统级 30% 效率提升中的相当大比例。

评判智能体的演进方向则是从“给反馈的评审者”变成“自动化测试套件”。改造后的评判智能体使用二元的“通过/失败”判定逻辑,拥有明确的拒绝标准,并设有迭代次数上限以防止无限循环。这与 XML 验证系统中的正式验证阶段高度同构。

在方法论层面, Ajay Dhanysi 将这套实践提炼为几条可复用的原则。角色清晰性要求每个智能体的提示词都能清楚回答:这个智能体的角色是什么,明确禁止它做什么,它是执行者、分析者、验证者还是协调者,以及是否允许它具有创造性,如果不允许,是否已在提示词中明确禁止。如果两个智能体的职责存在重叠的可能,则至少有一个提示词是欠规范的。

约束编码的逻辑与合同相同:不可谈判的约束必须显式列出,行为等价性等关键要求需要写明,平台特性(如 Apache Beam 的执行特性)需要声明,“希望实现”的目标要与“绝对不能破坏”的规则分开。 Ajay Dhanysi 给出了一个实用的判断标准:如果一个规则是人类评审者会默认存在的,那智能体就需要把它白纸黑字写进提示词。

失败模式驱动的演进是整套方法的核心。智能体重新解读了业务逻辑,就禁止解读。智能体提前进行了优化,就禁止优化。智能体在歧义中猜测,就要求澄清。输出格式出现漂移,就锁定格式。提示词的演进应该是对真实失败的反应,而不是对理论风险的预防。

在架构演进上, Ajay Dhanysi 进一步将单一评判智能体扩展为多智能体评估流水线。任务执行智能体生成待评估的输出,评估协调智能体( Evaluation Orchestrator )负责路由而不做任何评判,逻辑与准确性评判智能体、行为正确性评判智能体以及语气与标准评判智能体各司其职,最终由聚合与决策智能体执行算术运算和阈值判断,以 JSON 格式返回结果。每个智能体只评估一个维度,评估结果因此既可复现,又便于排查问题。

这套结构与他在 Apache Beam 重构中应用的原则完全相同:分析、生成与评判三种职责不能共享,必须分离。 30% 的效率提升背后没有魔法,只有对评判逻辑的解耦,以及对提示词的精准外科手术式演进。

相关文章

多智能体为什么比单智能体强?Anthropic 用 90.2% 的数据给了答案
智能体工程
2026年6月2日
0 条评论
零重力瓦力

多智能体为什么比单智能体强?Anthropic 用 90.2% 的数据给了答案

Anthropic 研究显示,多智能体系统性能比单智能体提升 90.2%,其核心在于主智能体拆解任务与子智能体并行执行。尽管该架构 token 消耗约为单智能体的 15 倍,但在复杂任务中优势显著。业界已总结出五种协作模式,并有 n8n、CAMEL-AI 等落地案例。然而,多智能体仍面临调试难、输出不稳定等挑战。建议仅在任务复杂需并行、分工明确且能承担高成本时采用,简单任务直接使用强模型即可。

#智能体#智能体工程
阅读全文
别被多智能体的概念吓住,真正跑通工作流的人都在关注这些细节
智能体工程
2026年6月1日
0 条评论
零重力瓦力

别被多智能体的概念吓住,真正跑通工作流的人都在关注这些细节

多智能体协作在创意交付端仍存短板,但在结构化任务中价值显著。实测显示,Super Agent 生成幻灯片虽快但排版难控,而自动化销售线索处理及编程辅助等场景因规则明确、流程可定义,能实现高效落地。多智能体的核心竞争力在于清晰定义职责边界、输出格式与异常处理,而非概念本身。建议优先梳理任务结构化程度与人机分工,注重参数配置等实操细节,避免盲目追求平台概念,以构建真正可用的生产力工作流。

#智能体工程#智能体
阅读全文
OpenClaw 遇到对手了:Hermes Agent 的自我进化路线到底能不能跑通
智能体工程
2026年5月28日
0 条评论
零重力瓦力

OpenClaw 遇到对手了:Hermes Agent 的自我进化路线到底能不能跑通

开源个人 Agent 领域呈现 OpenClaw 与 Hermes Agent 的路线之争。OpenClaw 主打全平台覆盖与可视化协作,强调交互广度;Hermes Agent 则聚焦自我进化与跨会话用户建模,追求认知深度,并提供一键迁移工具争夺用户。尽管 Hermes v0.14.0 已具备生产级能力,但其自我进化机制仍面临技能质量、记忆膨胀及 token 效率等挑战。这场竞争标志着个人 Agent 赛道已从功能验证迈向设计哲学比拼的新阶段。

#Hermes Agent#OpenClaw#智能体工程
阅读全文
互动讨论

评论区

围绕《Prompt Evolution :迭代提示词设计让多智能体性能提升 30%》展开交流,未登录用户可浏览评论,登录后可参与讨论。

评论数
0
登录后参与评论
支持发表观点与回复一级评论,互动后将同步到消息中心。
登录后评论
暂无评论,欢迎成为第一个参与讨论的人。