调研：多 agent 协作领域同类项目与 HALF 定位对比

[keting]

背景

HALF 当前定位是 human-in-the-loop 的多 AI coding agent 协作控制台：负责项目级任务编排、prompt 分发、状态跟踪、Git 结果回写观察和 agent 可用性管理，但不直接调用 agent 或绕过第三方产品的合规边界。

为了判断后续 roadmap 与产品边界，需要系统调研多 agent 协作 / 编排 / coding agent 管理领域的同类项目，形成一份可复用的调研报告。

建议调研范围

• 多 agent 编排框架：例如 AutoGen、CrewAI、LangGraph / LangChain Agents、MetaGPT、OpenHands 等。
• coding agent / 软件工程 agent 平台：例如 Claude Code、Codex、Cursor、GitHub Copilot Coding Agent、Devin、OpenHands 等。
• 人在回路中的 agent workflow 工具：关注任务拆分、人工审批、状态追踪、产物归档、团队协作和合规边界。
• 与 HALF 相近但产品定位不同的项目：自动 runner、agent IDE、workflow orchestrator、project board、研究型 multi-agent benchmark 等。

希望产出

形成一份调研报告，建议包含：

1. 项目清单：名称、链接、开源/商业属性、主要使用场景、目标用户。
2. 能力对比：任务编排、DAG/依赖、agent 调用方式、人工介入点、状态追踪、Git 集成、权限/审计、可扩展性。
3. 合规与边界：是否依赖官方 API、是否自动化第三方订阅式 agent、是否涉及 UI 自动化/逆向/凭证共享风险。
4. 与 HALF 的差异：哪些能力 HALF 已覆盖，哪些是明确 non-goals，哪些值得作为后续候选方向。
5. Roadmap 建议：短期可做的文档/UX 改进，中期可验证的产品能力，长期需要继续观察的方向。

开放问题

• HALF 是否需要维护一份公开的同类项目对比文档？
• 哪些项目应作为第一批重点调研对象？
• 调研报告应放在 docs/research/、GitHub Discussion，还是作为 roadmap 附件维护？
• 这类调研是否应该定期更新，还是仅在重大 roadmap 决策前更新？

初步倾向

先以 Discussion 收集范围和对象，再落一份 docs/research/ 下的 Markdown 调研报告。报告完成后，再从结论中拆出具体 issue 或 roadmap 调整项。

Originally posted by @keting in #72