编码代理是否缺少架构层？我构建了一个开源代理工具来实验这一想法

我一直在思考一个问题，随着编码代理承担更大、更长时间运行的任务，这个问题变得越来越重要：软件架构是否应该成为代理控制循环中的显式部分？当前大多数编码代理大致遵循这样的循环：任务 → 探索代码库 → 推理 → 编辑代码 → 运行工具/测试 → 迭代。这出奇地有效，但随着任务规模增大，我一直在想，是否我们每次都让代理从代码库中重建太多架构意图。因此，我尝试了一种不同的方法：需求 → 架构 → 代理 → 代码 → 测试 → 修复。这个想法不是将UML用作文档。相反，我在探索架构是否可以作为人类意图和实现之间的结构化中间表示——代理可以检查、推理、验证并提出更改。例如，组件图可以描述系统边界和依赖关系，类图可以表示结构约束，序列图可以捕获重要交互。编码代理仍然会检查和修改实际代码库，但它会有另一个表示系统应该是什么样子的模型。我围绕这个想法实现了一个工作原型。代理本身目前使用ReAct风格的循环，可以检查/编辑文件、执行命令、运行真实测试、修复故障、维护任务计划，并提交架构更改供人类审查。我还在尝试一些相关想法：有界子代理——子代理探索项目并返回结构化证据，但主代理负责修改和验证。跨会话记忆——可以将先前任务中的有用信息检索到未来的代理运行中。架构+代码知识图谱——连接设计实体、代码实体、关系和测试覆盖率。完整执行轨迹和回放——记录LLM交互和工具调用，以便检查和重现代理行为。代理评估——在受控项目固定装置上运行生产代理，使用硬检查器检查测试、代码结构、架构有效性、文件完整性、令牌使用、工具调用和执行时间。评估部分实际上让我更加质疑架构想法。架构为代理提供了额外的结构化上下文，但它也引入了另一个需要与现实保持同步的表示。因此，似乎存在一个根本权衡：架构可以减少歧义，但架构漂移可能创建第二个事实来源。也许更好的方向根本不是架构。也许足够好的代码库搜索、代码智能、上下文检索和记忆允许代理在需要时重建架构。或者，架构表示应该从代码动态生成，而不是独立维护。我很好奇构建代理的人们对此有何看法。对于长期运行的编码代理，你是否希望在需求和代码之间有一个显式的架构表示？或者代码库是否应保持为唯一事实来源，代理按需推导架构理解？我特别关注从事编码代理、代理工具、上下文工程、记忆、规划或多代理系统工作的人们的经验。我已将用于这些实验的原型开源。我会把它放在评论中，供任何想查看实现或进行实验的人参考。