我构建了ARGO，一个开源Agent Loop框架，用于可追踪的AI编码交付

在较大的AI编码任务中，我反复遇到同一种失败模式：智能体可以快速生成代码，但需求背后的决策、架构边界和验收标准却在多次会话之间消失了。当测试失败时，最简单的应对是修补代码。但有时真正的问题是一个未经审视的实现假设——甚至是上游某个不清晰的业务决策。我构建ARGO就是为了让这条交付链路变得明确。它是一个开源、可安装到工作区的Agent Loop框架，支持Cursor、GitHub Copilot和OpenCode。 ARGO结合了两个理念：一个ArchiMate结构化的意图图。目标、能力、约束、依赖、工作包和明确的验收测试用例都保存在SystemArchitecture.json中，该文件始终是规范的事实来源。GraphRAG语义检索加上一个分阶段的Agent Loop。它帮助智能体在意图图中导航，然后推动工作依次经过业务澄清→意图设计→实现设计→编码/修复→两级验收→归档。每个阶段都有清晰的职责边界。 意图设计负责验收的含义；实现设计创建稳定的边界和测试入口；编码更改生产行为，但不能重写已冻结的验收测试来人为制造通过。 两个验收级别是有意设计的：代码是否满足实现契约？实现是否满足原始业务意图？如果任一答案为否，GAP会回到负责它的阶段，而不是把每次失败都当作代码缺陷。 有两种运行模式：人在回路中（human-in-the-loop）模式，用于持续审批；以及监督式自主模式，用于边界清晰且可执行验证的任务。 这刻意比提示链或轻量级规格工作流更重。我认为它适合高风险、多团队或需要审计的交付；而小规模、低风险的任务在没有完整框架的情况下可能更快。 GraphRAG的语义功能还需要环境配置（包括Neo4j连接和配置好的向量生命周期）。 我非常重视以下方面的批评性反馈：你的智能体在多次会话之间丢失了哪些决策？你如何判断一个失败是意图、架构还是实现问题？这些阶段边界是有用，还是对实际工作来说过于僵化？