如何构建代理图

在过去的4个月中，通过处理图，我艰难地学到了几个关于图设计的重要教训。在这篇文章中，我想分享主要的要点，以便你不会重复我的错误。首先，我对图的定义：代理图（也称为工作流）是允许循环的有向图，描述了在代理（节点）之间如何通过预定义的转换（边）在循环中传递工作。图由分支、循环、脚本和转换（以及它们的提示和参数）组成。并行不是万能药起初，我对图中的并行分支非常热情。但随着时间的推移，我意识到并行不仅会增加成本，还会减慢任务执行速度。一个标准的并行检查组可能包括代码审查、QA和范围审查。当这些阶段在循环内部时，问题就开始了。举个简单的例子。假设代码审查、QA和架构审查并行运行，之后如果需要，任务返回到实现阶段。如果架构审查通过，但代码审查发现几个小问题，任务返回到实现代理。一旦修复完成，它会再次进行审查——架构审查者必须重新检查更新的差异，即使之前的版本完全可接受。在循环图中，并行检查常常导致重复工作、缓存失效和不必要的成本，而没有实际好处。理论上，这个问题可以通过智能路由器解决。Kent通过脚本节点支持这一点：路由器可以确定代理是否完成了整个实现，还是只处理了特定审查者的反馈（kent.sh是我免费开源的构建代理图项目。我提到它是因为我自己在使用，并且不知道有其他类似产品。你可以将这个建议应用到任何类似的编排器上）。然而，这让我们回到了试图通过代理图避免的问题：代理再次决定需要运行哪些验证阶段。这否定了图的大部分价值。实际上，解决方案更简单：依赖检查应该顺序执行。在我的工作流中，架构审查总是在代码审查之前。只有在架构批准后，任务才会进入代码审查。这就是为什么我移除了许多并行阶段，现在通过避免对在其他阶段会被拒绝的结果进行检查来节省令牌。这种方法在规划、代码审查和QA方面特别有效。例如，代码审查应该首先过滤实现问题，然后QA才开始。否则，两个阶段可能独立地找到相同的bug并产生重复的反馈。代理必须能够挑战反馈起初，绝对主义和独裁统治着我的开发代理图：每个审查评论都必须处理，否则任务无法进行。但审查者并不总是产生正确的结果。现在，我的图中的每个代理都可以向我提问，并澄清如何处理冲突的反馈。例如，范围审查可能会拒绝代码审查刚刚要求的测试，因为它认为任务验证不完整。同时，代理不能完全信任自行解决这些冲突。即使使用像Sol这样的新模型，你也可能陷入修复虚构或吹毛求疵问题的无限循环。我通过将最终决策委派给我自己来解决这个问题（纯粹的选择，我喜欢参与）。你也可以将其交给PM代理或设置多个代理之间的通信。例如，在Kent中，代理可以获取其他会话ID，以便他们可以讨论情况并达成妥协。Anthropic在他们最近的论文中认为这是模型的问题。我不同意——这是工具的问题，我上面的系统证明了这一点。图必须有一个机制来升级冲突或可疑的反馈——否则，审查会变成一种独裁，能够将整个工作流困在循环中，或者一场固执的战争。不要忘记静态检查代理图听起来令人兴奋，很容易想要创建数十个代理和验证阶段。这确实可以减少主要代理的认知负担并提高其工作质量，但静态检查应该优先。起初，我的实现代理自己运行代码检查器、架构测试和单元测试，打开PR，并检查传入的评论。我意识到这不过是盲目模仿，然后决定将这些操作移动到代理图中的脚本节点。现在，一个单独的阶段：运行所需的静态检查和测试；正确管理机器的共享资源；过滤结果；只向实现代理返回相关信息；只在需要其参与时再次调用代理。如果测试是绿色的，实现代理甚至不知道它：没有新的回合开始，这意味着代理没有花费一个令牌来运行测试或阅读其结果。不要将LLM分配给常规脚本可以更可靠、更便宜执行的工作。在工作流规模上，这会产生显著的节省。为任务选择合适的模型如果你不优化图的令牌使用和成本，你可能会因为许多任务在更新的工作流下会变得多余而过度支出。过去，我们在工具中使用一个模型处理所有事情，因为我们别无选择。你现在不需要这样做，正确分配模型和资源可以节省大量资金。在标准工具中，你通常可以切换模型，但这会使缓存失效。此外，你要么保留上一个会话的杂乱上下文，要么启动一个新的并手动引导/提示它。Kent解决了这些问题，所以不要害怕为代理创建不同的角色。例如，手动QA可以在像DeepSeek或Luna这样的廉价模型上运行，这些模型几乎不花费任何费用或几乎不影响你的订阅配额。然后，最智能的模型可以保留给关键阶段，例如规划。众所周知，如果你有一个好的计划，你可以将实现分配给能力较差的模型，并获得几乎相同的结果。此外，额外的验证阶段进一步降低了实现任务所需的最低模型智能水平。从版本2.6开始，Kent原生允许一个代理在沿图边转换后选择下一个代理的模型、系统提示角色和推理级别。这使得可以：将简单任务和错误修复委托给像Luna这样的模型；在具有高限制的廉价模型上运行QA；将简单决策交给本地模型；为复杂规划和关键检查保留最强大的模型。密切关注缓存和回合之间的时间我测量了阈值，在缓存未命中后继续会话的概率——并支付数倍费用——变得足够高，以至于预防性压缩是值得的。 推测性压缩（对于常规会话）在上下文使用率约88%时变得值得，根据这个草图。对于工作流，我的统计阈值大约是71%想象实现代理花了40分钟处理代码审查反馈。在此期间，审查代理的缓存可能已经失效。当他们第二次审查工作时，Kent会提前压缩会话，以便审查继续使用新的上下文，而不会因缓存未命中导致不必要的成本。但这只是一个启发式方法。你仍然应该考虑连续调用同一代理之间的时间间隔。如果工作流很长，节点等待工作返回很长时间，缓存失效的可能性会增加。在这种情况下，有两个主要选项：使用压缩并继续模式