夜雨聆风过去一年，AI 辅助编程从新鲜事物变成了日常工具。在编辑器里让模型补一个函数、修一个 Bug、生成一个页面，甚至完成一轮小型重构——这些体验已经相当流畅。
但当任务从“改一段代码”变成“交付一个完整功能”，事情就变了。
谁来澄清需求？谁来拆分任务？哪些任务可以并行？写完代码之后谁来验证？测试失败了是自动返工还是打断用户？多个分支如何集成？踩过的坑要不要记下来、怎么记？
这些问题不是模型能力问题。它们更像一家软件公司的日常经营问题——只是这家公司里目前只有你一个人，加上几个只会写代码的 Agent。
这也是我在做 Argora 的原因。
Argora 是什么
Argora 是一个面向多 Agent 软件研发的编排系统，定位是“自主 AI 软件公司”的运行底座。它通过 Argora Cloud 提供 SaaS 服务，也可以完全离线运行（离线版本暂未独立发行）。
它不是一个更大的聊天窗口，也不是把多次模型调用简单串成一条流水线。它在尝试建立一套可以持续运行、可以审查、可以恢复、可以追溯的研发流程——从捕捉一个想法开始，经过提案讨论与修订、形成产品文档、拆解为可执行的工作队列，到多 Agent 并行执行、验证、评审与返工，再到集成检查和最终验收，全程留下记录和记忆建议。
在这套模型里，用户不再是每个 Agent 的现场监工，而更像是公司的 Owner 或 CEO——负责提出方向、做关键决策、批准高风险变更、验收最终结果。Argora 承担的是 COO 和项目经理的职责：组织计划、分派任务、推动执行、收集证据、处理常规失败、准备交付材料。
用户决定做什么，Argora 负责让这件事可靠地发生。
为什么单个 Coding Agent 还不够
单个 Agent 处理边界清晰的任务非常高效。但真实的软件研发链路更长，一个看似简单的需求背后需要：
- 把一句模糊想法整理成多个可选方案
- 明确产品行为、验收标准和不做什么
- 将工作拆成可以独立执行、独立验证的单元
- 让不同 Agent 在隔离环境中并行工作
- 用记录下来的测试结果替代“应该没问题”
- 让 Reviewer 检查别人的代码，而非作者自审
- 评审要求修改时自动进入有限次数的返工
- 在合并前准备完整证据，交给人做最终决定
如果这些环节全靠用户手动推动，AI 省掉的编码时间又变成了管理负担。Argora 想解决的是这部分成本。
把用户从操作员变成 Owner
Argora 的核心设计判断是：人不应该是每个任务的默认调度员、QA、代码审查员和合并工程师。
值得打断用户的，是决策级问题：
- 选择哪一个产品方向
- 是否批准一份明确的 PRD
- 是否执行高风险任务
- 是否接受范围、成本或安全边界的变更
- 是否提交最终结果
- 是否将某条经验写入长期记忆
普通工程摩擦应该在系统内部闭环处理：
- 测试失败
- Reviewer 提出修改要求
- Agent 超时且允许重试
- 小范围实现修正
- 常规依赖排序
- 可以安全处理的集成冲突
这个区分很关键。它本质上决定了产品是“一个需要持续操作的工具”还是“一支可以委托的团队”。
一次任务在 Argora 里如何流转
假设你对项目提出一个需求，比如“给团队协作功能增加邀请机制”。Argora 不会直接让 Agent 冲进去改代码。
1. 先讨论方向
系统将初始想法展开为结构化提案，列出假设、取舍、风险和推荐方案。不同方案可以独立修订和对比。用户最终批准的是一份明确的方案版本，而非一句模糊的聊天记录。
2. 再形成产品合同
批准方向后，Product Agent 继续生成 PRD，补齐用户目标、功能要求、边界条件、验收标准和待确认问题。
在 Argora 的设计中，批准的提案是战略方向，批准的 PRD 是产品合同。两者都足够明确，实现才启动。
3. 把工作拆成可执行队列
Planner 将 PRD 转化为任务图和工作队列。每个任务包含：
- 允许修改的文件
- 禁止修改的文件
- 依赖关系
- 验收条件
- 验证命令
- 风险等级
Agent 拿到的不是一句“帮我做完”，而是一份边界清楚、可以验证的工作订单。
4. 在隔离环境中并行执行
每个实现任务运行在独立的 Git worktree 和独立分支中，多个 Agent 可以并行推进互不依赖的任务，失败任务不会污染主工作区。
5. 自动验证、评审与有限返工
Worker 完成代码后，系统按预先声明的验证规则自动检查，记录执行结果和状态。验证失败就是失败，不会伪装为通过。
随后 Reviewer 检查另一个 Agent 生成的代码。如果结论是需要修改，任务进入返工队列，在限定次数内自动修正——不把例行问题抛给用户。
6. 最后进入提交决策
所有任务完成后，Argora 准备最终分支、集成报告、变更摘要、验证结果、评审记录和已知风险。只有当用户明确批准最终提交，Argora 才将结果合并到当前分支。它不会自动推送远端，也不会静默修改主分支。
可追溯比”看起来完成了”更重要
AI 研发工具很容易给人流畅的错觉：模型输出代码，终端滚过日志，好像就结束了。但“似乎完成”在真实项目中远远不够。
Argora 将每次运行的关键证据保存在项目中：提案与修订记录、已批准的计划与 PRD、工作队列与任务图、Agent 输出、验证结果、评审结论、返工历史、事件时间线、集成报告、最终报告，以及待审批的记忆建议。
这些记录的意义不在于让用户每天全部阅读，而在于每个决策都有据可查，每次失败都可以回溯，每份结果都可以被审查。
记忆也必须经过审批
长期运行的 Agent 系统一定会遇到“学习”问题。比如一次测试失败后系统发现，这个项目的集成测试必须设置某个特定的环境变量。这显然值得记录。
但 Argora 不允许 Agent 直接修改长期记忆。正确流程是：Agent 发现可复用经验后，生成记忆更新建议，系统保存为待审批状态，用户接受或拒绝，通过后才写入正式记忆。
原因很直接：记忆会影响未来决策。它不是普通日志，而是系统的知识和规则库。自动收集是必要的，自动生效必须受控。
CEO Console：为 Owner 设计的决策界面
Argora 通过 Argora Cloud 提供 CEO Console——一个围绕决策组织的 Web 界面，也支持完全离线运行。
它的设计逻辑不是”接下来做什么操作”，而是”当前需要做什么决策”、”Argora 推荐什么”、”证据在哪里”。目前已覆盖 Mission Control、提案工作区、PRD Studio、Decision Center、工作队列、最终验收和 Evidence Inspector 等核心页面。
当前进展与边界
目前 Argora 已完成单用户闭环的验收，正在推进 Argora Cloud SaaS 服务的上线准备。如果你对这个方向感兴趣，欢迎赞助支持。如需申请演示环境，可关注公众号留言"Argora 演示"。
当前重点：
- Web Console
- Codex 和 Claude 适配
- 基于文件系统的持久化运行记录
- Git worktree 隔离
- 工作队列、验证、评审和有限返工
- 集成准备与 Owner 批准后的本地提交
- 可审查的记忆建议
目前明确不在范围内的能力：
- 自动创建 GitHub PR
- 浏览器内代码编辑
- 自动应用长期记忆
- 自动解决复杂合并冲突
保持边界感很重要。Argora 的目标不是用“全自动”掩盖不确定性，而是把可自动化的部分真正做好，把需要人判断的问题坦率地交还给人。
最终想成为什么
我希望 Argora 最终带来的不只是少写代码。
而是让更多人能够以软件 Owner 的身份工作：有想法但不必亲自拆每张任务卡，能判断方向但不必盯住每次模型调用，需要掌控风险但不必阅读所有日志，希望 AI 自主推进但真正重要的批准权仍在自己手里。
如果 Coding Agent 让一个人拥有了一位随叫随到的工程师，那 Argora 想继续往前走一步：
让一个人拥有一支可以被委托、可以审查、可以被管理、也会持续积累经验的软件团队。
这是一个仍在成长的项目，但它已经不只是一个关于“让 AI 多写代码”的实验。它更像在回答另一个问题：
当 AI 开始承担越来越多软件研发工作时，我们需要的到底是一个更强的 Agent，还是一间真正会运转的公司？
