AgentCrew 快速上手：用 Markdown 给 AI 编码 Agent 装上团队流程

你让 Claude Code 或 Codex 添加一个 Google OAuth 登录。几秒后，它直接开始改文件。它改了路由、认证中间件、数据库 schema，顺带更新了测试文件——然后告诉你”完成了”。问题是，你只想要一个简单的登录按钮。那数据库迁移是怎么来的？那测试真的跑通过吗？

这不是模型能力的问题。这是流程问题。

在真实软件团队里，架构师、开发者、测试员、安全审核员各自有分工。但 AI 编码 Agent 的默认工作模式是一个上下文做所有工作：需求分析、编码、测试、审核、合并——全都是同一个模型会话。

AgentCrew 就是来解决这个问题的。

一分钟理解 AgentCrew

AgentCrew 是一套 Markdown 优先的编码 Agent 方法论。它不是守护进程，不是 CI 系统，也不是另一个 Agent 工具——它是一套流程层。你的 Agent 加载了 AgentCrew 之后，会按照你的项目预设的步骤来工作：先分类任务，再确定角色，按流程执行，最后把决策权交给人类。

项目地址：github.com/mlguyYT/AgentCrew（MIT 许可证）

5 分钟安装

AgentCrew 的安装非常简单，因为它本身就是一套 Markdown 文件和 Shell 脚本：

git clone https://github.com/mlguyYT/AgentCrew ~/AgentCrew
cd ~/AgentCrew
./bin/agentcrew install

install 命令会自动在你的 Host Agent 配置文件中写入一条加载指令。支持的操作系统包含：

安装完成后运行验证：

./bin/agentcrew doctor

如果一切正常，你会看到方法论路径、Agent 配置文件、Shell 环境均检查通过。

核心概念速览

AgentCrew 的工作流程围绕几个核心原语构建：

双车道系统

不是什么任务都需要走完整的开发流程。AgentCrew 把工作分为两个车道：

• 快速车道（Fast Lane）：适用于 typo 修复、简单的文档更新、低风险的小改动。追求速度。
• 完整车道（Full Lane）：适用于认证/授权变更、支付逻辑、数据库迁移、安全敏感代码、大型重构。追求安全。

当你给 Agent 发送一个请求时，纯 Bash 分类器会先判断应当走哪个车道。

角色体系

Agent 不再是一个全能的上下文。AgentCrew 定义了多种角色，每种角色有不同的指令约束：

• Advisor：实施前先做分析
• Product Manager：明确范围和验收标准
• Developer：专注最小化实现，禁止无关修改
• Tester：运行验证，报告测试结果
• Reviewer：审查正确性、可维护性和风险
• Security Reviewer：检查敏感路径

关键设计：同一模型在切换角色时使用不同的约束，而不是假装有不同的”人”。

人工审批关卡

这是 AgentCrew 最重要的设计原则：Agent 可以准备工作，但人类最终决定是否合并。核心规则包括：

• Agent 不能合并自己的代码
• Agent 不能绕过分支保护
• Agent 不能隐藏失败的测试
• Agent 不能谎称未运行的测试已通过
• Agent 不能提交密钥
• 生产级代码必须经过人工批准

实战场景一：简单 Bug 修复

假设你在项目中发现一个 typo：

User request: 修复登录页面按钮文字拼写错误 "Sing In" → "Sign In"
AgentCrew route:
- Lane: Fast (低风险，局部修改)
- Starting role: Developer
- Required outputs: 最小化 diff

在快速车道模式下，Agent 直接找到文件、修改一行文字、不需要测试覆盖、不需要安全审核。整个流程几秒完成。

实战场景二：添加 OAuth 登录（完整车道）

当请求涉及安全敏感的认证逻辑时：

User request: 为注册流程添加 Google OAuth 登录
AgentCrew route:
- Lane: Full
- Risk: Security-sensitive
- Starting role: Product Manager
- Required roles: Developer, Tester, Security Reviewer
- Required outputs: work plan, test report, security review, human decision log

Agent 不会直接改代码。它会先澄清范围（这个 PR 应该包含哪些文件？需要哪些 OAuth scope？回调 URL 是什么？），然后制定工作计划，再按照 Developer → Tester → Security Reviewer 的顺序执行，最后准备一个清晰的交接文档交给人类审核。

实战场景三：大型重构

重构是最容易被 Agent 搞砸的场景。一个”看起来无害”的 API 重命名，可能被 Agent 扩展到不相关的模块。AgentCrew 的三层防护：

1. 范围约束：Agent 的系统提示中明确禁止「默默扩大范围」和「做无关修改」
2. 状态追踪：重构的每个阶段会写入 .agent-state/work-plan.md，Agent 必须跟踪当前在做什么
3. Reviewer 回检：重构完成后，Reviewer 角色会检查 diff 中是否存在不应被修改的文件

.agent-state/
├─ current-task.md        # 当前任务描述
├─ work-plan.md           # 工作计划
├─ human-decisions.md     # 人工决策记录
├─ handoff.md             # 交接文档
├─ test-report.md         # 测试报告
└─ session-checkpoints/   # 会话检查点

为什么是 Markdown？

AgentCrew 选择用 Markdown 而非配置语言或代码来定义流程，因为：

• Markdown 是人类和 Agent 都容易阅读的格式
• 修改流程不需要理解编排引擎的内部
• 角色定义、Playbook、技能模板都是可见的文件，可以版本控制和 Review
• 用户可以按需自定义：调整分类器阈值、添加新角色、修改审核检查清单

项目目录结构展示了这套透明性：

agent-team/
├─ agents/         角色定义
├─ playbooks/      工作流指南
├─ recipes/        具体场景的工作流配方
├─ protocols/      交接格式和安全边界
├─ checklists/     合并前检查清单
└─ skills/         按需加载的技术技能

什么时候该用？

AgentCrew 尤其适合以下场景：

• 多人协作项目：Agent 生成的代码需要经过正式 Review
• 安全敏感代码：认证、支付、权限相关变更需要额外关卡
• 大型代码库：防止 Agent 修改超出范围的模块
• 团队流程规范化：用代码化的方式定义团队对 Agent 的期望

如果只是个人玩具项目、一次性脚本或快速原型，快速车道模式就足够了——AgentCrew 的双车道设计让它能兼顾速度和安全性。

总结

AgentCrew 不是要取代你的判断力。它给编码 Agent 加上了一层流程约束，让 AI 从「一个什么都干的上下文」变成「一个有团队分工的协作系统」。安装 5 分钟，带来的好处是：更少的意外修改、更规范的 PR、更容易信任 Agent 的输出。

官网：https://github.com/mlguyYT/AgentCrew 许可证：MIT