SWE-AF 工程团队运行时
把软件需求交给可规划、编码、测试并交付 PR 的自治工程团队。
按维度查看评分与理由
证据显示：README 提到 API 密钥加密存储、GH_TOKEN 仅用于私有仓库克隆和 PR、HITL 计划审批门（hax-sdk）等，但未提供具体实现细节或权限最小化分析。扣分原因：缺乏代码级证据，权限范围描述不完整，用户确认机制仅提及未证实。
证据显示：README 和 CI 配置一致，依赖版本固定（如 claude-agent-sdk==0.1.20），CI 包含测试和 Go 构建。扣分原因：未提供失败消息的具体示例，依赖可用性仅基于声明。
证据显示：README 详细描述了单仓库和多仓库模式、多种运行时（claude_code, open_code, codex）、模型映射和 Docker 部署。扣分原因：能力边界未明确，触发条件（如 replanning）描述不精确，环境适配依赖外部组件。
证据显示：README 结构清晰，提供安装步骤、示例、Docker 部署、API 参考链接；LICENSE 为 Apache-2.0；pyproject.toml 定义版本。扣分原因：缺少 CHANGELOG 和版本历史，维护责任未明确，已知限制未系统列出。
证据显示：README 提供基准测试结果（95/100）和成本数据（$19.23），展示输出可用性。扣分原因：成本效益分析基于单一案例，未提供独立验证。
证据显示：README 提供基准测试方法和示例 PR 链接，但未提供可复现的完整日志或第三方验证。扣分原因：声明与证据分离不清晰，缺乏独立来源佐证。
- 发布者身份未验证，应视为未知，不要基于品牌信任。
- README 中的性能基准和成本数据未经独立验证，需谨慎对待。
- 依赖固定版本但未提供漏洞扫描证据，建议检查依赖安全性。
- 权限最小化、用户确认等安全机制仅提及，需审查实际实现。
这个 Agent 能做什么，适合哪些场景？
SWE-AF 是构建在 AgentField 上的自治软件工程团队运行时，注册为 swe-planner 和 swe-fast 节点。一次 build 调用会依次生成 PRD、架构、问题依赖 DAG，并在隔离 Git worktree 中让编码、QA、审查和合并角色协作。它支持 repo_url 远程仓库、repo_path 本地工作区，以及带 primary 和 dependency 角色的多仓库构建。完成后可产出提交、分支、验证结果和可选 GitHub PR；执行状态可通过 AgentField 的 executions API 查询。仓库同时维护 Python 实现与 Go 节点：af install 安装 Go 节点，Python 模式可通过 python -m swe_af 或 Docker Compose 运行。
调用 swe-planner.build 时，系统先运行 run_product_manager、run_architect、run_tech_lead 与 run_sprint_planner，将目标分解为问题 DAG。每个问题在独立 worktree 中经 run_coder、run_qa、run_code_reviewer 和 run_qa_synthesizer 处理；失败可由 run_issue_advisor 调整、拆分或升级，并由 run_replanner 重构剩余 DAG。随后 run_merger、run_integration_tester 与 run_verifier 合并并核验验收条件，工件写入 .artifacts/plan、execution 和 verification。对于已明确范围的任务，可调用 swe-planner.implement_issue，跳过规划，仅返回隔离分支、提交、改动文件和验证结果；启用 enable_github_pr 时还可推送并创建 PR。
- 负责单个 GitHub 仓库的工程负责人，需要把“新增 JWT 认证”这类功能需求分解、实现、测试并形成可审查的 PR。
- 维护主应用和共享 SDK 的团队，需要用 config.repos 同时协调 primary 仓库与 dependency 仓库的改动。
- 使用 Claude Code、Codex 或 OpenCode 作为主编程工具的开发者，想把已写清的单个 issue 委派给 implement_issue，并自行合并返回分支。
- 希望在 CI 失败后执行受限修复循环的仓库维护者，需要让已创建 PR 的 GitHub Actions 检查被持续监视。
- 需要在本机工作区完成改动、又不希望调用方当前分支和未提交状态被触碰的开发团队。
这个 Agent 有哪些优点和局限？
- 完整流水线覆盖需求拆解、架构审查、并行编码、QA、合并、集成测试与验收核验，而不是只有单一编码循环。
- 通过依赖调度和隔离 Git worktree 支持并行执行，可避免多个问题同时修改时的分支冲突。
- 提供三层适应控制：单问题重试、issue advisor 调整，以及剩余 DAG 重新规划。
- 可按角色指定模型，并支持 claude_code、open_code 与 codex 运行时。
- implement_issue 为上层编程 harness 提供低于完整 feature 构建的 issue 级委派入口，并保持调用方工作树不变。
- 完整 build 设计为功能级流程，文档说明可能耗时数小时，并会产生数百次甚至更多 LLM 调用。
- 运行依赖 AgentField、可访问的 Git 仓库、网络与 LLM 提供商凭据；私有仓库和 PR 工作流还需要 GH_TOKEN。
- 多模型配置、角色覆盖、重试预算和 Docker 环境变量带来较高的运维与成本管理复杂度。
- Docker 中使用 Codex 运行时必须显式设置 SWE_DEFAULT_MODEL 或每次传入 Codex 模型；否则可能错误解析到 OpenCode 模型标识。
- Codex 的 workspace-write 沙箱依赖 Linux 用户命名空间；部分 WSL2 或强化环境会因 bwrap 权限失败而无法写入文件。
如何安装或部署这个 Agent？
已有 AgentField 控制平面时，可执行：
af install https://github.com/Agent-Field/SWE-AF
af run swe-planner首次运行需提供一个 LLM 凭据：ANTHROPIC_API_KEY 或 OPENROUTER_API_KEY；如需访问私有仓库、推送分支或创建 PR，再配置带 repo 权限的 GH_TOKEN。Python 本地运行方式为创建 Python 3.12+ 虚拟环境后执行 python -m pip install -e ".[dev]"，启动 af，再执行 python -m swe_af。
如何使用这个 Agent？
最小调用示例：
curl -X POST http://localhost:8080/api/v1/execute/async/swe-planner.build \
-H "Content-Type: application/json" \
-d '{"input":{"goal":"Add JWT auth","repo_url":"https://github.com/user/my-project"}}'若使用 Codex CLI，可在 config 中指定 "runtime":"codex" 与 "models":{"default":"gpt-5.3-codex"}。使用 ChatGPT 订阅认证时，主机需安装 Codex CLI 并完成 codex login，且设置 SWE_CODEX_AUTH_MODE=chatgpt 或 auto；API 平台计费则设置 SWE_CODEX_AUTH_MODE=api_key 和 OPENAI_API_KEY。
这个 Agent 与同类方案有什么区别？
仓库给出了同一 Node.js CLI 待办应用提示词的基准：其报告 SWE-AF 的 haiku 路由和 MiniMax M2.5 路由均为 95/100，而 Claude Code Sonnet 为 73、Codex o3 为 62、Claude Code Haiku 为 59。该比较是项目提供的单一任务评分，适合用于评估其流程设计，不应视为所有软件工程任务的通用性能结论。