第 31 章 · 综合实战：五件套打通完整工作流
本章目标：把全课程的五件套——提示工程、MCP、Skills、AGENTS.md、Loop Engineering——串成一条完整的生产级工作流，以"每日代码审查循环"为例完成端到端落地，并画出各层职责边界。
24.1 五件套在链路中的位置
回顾整门课程：我们不是学了五个孤立工具，而是一个智能体系统的五个层次。它们自上而下的协作关系是：
┌─ 提示工程（01–09 章）────────────────────────────┐
│ 写好每一步指令：Few-shot 给范例、CoT 做推理、 │
│ ReAct 边想边做 —— 这是所有环节的"语言层" │
├─ MCP（10–15 章）────────────────────────────────┤
│ 给智能体接上真实世界：GitHub / CI / 数据库等 │
│ 工具通过标准协议接入 —— 这是"能力接入层" │
├─ Skills（16–18 章）─────────────────────────────┤
│ 把可复用的作业流程封装成 SKILL.md 能力包， │
│ 渐进披露按需加载 —— 这是"流程封装层" │
├─ AGENTS.md（23 章）──────────────────────────────┤
│ 固化项目上下文与规矩，常驻每个会话 —— "项目约定层" │
├─ Loop Engineering（19–22 章）────────────────────┤
│ 调度、状态、预算、人审门禁，让上面的一切 │
│ 持续自主运转 —— 这是"运行与治理层" │
└─────────────────────────────────────────────────┘一句话串起来：提示决定单步质量，MCP 决定能做什么，Skills 决定怎么做才稳定，AGENTS.md 决定在哪做守什么规矩，Loop 决定何时做和做多久。
24.2 实战目标：每日代码审查循环
我们要落地 loop-engineering 七大模式中最经典的 Daily Triage（每日分诊） 变体——每天早上自动审查昨天的提交与 PR，产出优先级清单，风险项交人工把关。
第一步：用 AGENTS.md 固化项目约定
这是循环每次运行的"地基"，智能体每次启动都会读到：
<!-- AGENTS.md -->
# 项目约定
## 构建与测试
- 安装依赖：`pip install -e ".[dev]"`
- 运行测试：`pytest -x -q`（必须全绿才算完成）
- 类型检查：`mypy src/`
## 代码风格
- 遵循 PEP 8；函数必须有类型注解与 docstring
- 禁止直接修改 migrations/ 目录下已应用的迁移文件
## 安全红线
- 不要移动或重命名 .github/workflows/ 下的文件
- 凭据一律走环境变量，禁止硬编码第二步：把审查标准封装成 Skill
审查规则会越来越长，放 AGENTS.md 会撑爆常驻上下文——按渐进披露原则封装为技能：
skills/review-checklist/
├── SKILL.md
└── references/
└── severity-rubric.md # 严重程度分级细则，按需加载<!-- skills/review-checklist/SKILL.md -->
---
name: review-checklist
description: 按团队标准审查提交与 PR：检查测试覆盖、错误处理、安全隐患并输出严重程度分级。当用户要求 code review 或审查变更时使用。
---
# Code Review Checklist
## 步骤
1. 用 `git log` 与 `gh pr list` 收集待审查变更；
2. 对每个变更逐项检查：
- 是否附带测试；错误路径是否处理；是否有硬编码凭据；
3. 按 references/severity-rubric.md 分级：blocker / major / minor；
4. 以 Markdown 表格输出，blocker 置顶。
## 规则
- 只报告问题，不要顺手修复（修复由后续 L2 循环负责）。
- 不确定是否问题时，标记为 needs-human 而不是猜测。注意第 6 章学的 ReAct 思想就藏在步骤里：先收集（行动）→ 再判断（推理）→ 再输出，而不是让模型一口气凭空生成。
第三步：用 MCP 接上 GitHub 与 CI
智能体需要读 PR 和 CI 状态的真实数据。第 13 章写过 MCP Server，这里直接复用社区现成的：
// .pi/agent/settings.json 或 Claude Code 的 mcpServers 配置
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": { "GITHUB_TOKEN": "<从环境变量注入>" }
}
}
}这样 review-checklist 技能里的 gh pr list 之外，模型还能通过 MCP 工具直接查询 PR 详情、CI 结果、代码差异——协议层保证了这些工具对所有支持 MCP 的客户端通用。
第四步：用提示工程打磨关键节点
循环里每一步的提示都应用前九章的技术：
# 分诊环节使用 Few-shot + 结构化输出约束
TRIAGE_PROMPT = """你是值班审查员。参考以下历史分级示例：
示例1：修复登录超时的补丁未带测试 → major（核心路径缺测试）
示例2：README 错别字 → minor
示例3：删除了输入校验 → blocker（安全回退）
现在请对以下变更分级，只输出 JSON 数组，
每项包含 pr_number, severity(=blocker/major/minor), reason：
{changes}
"""Few-shot 示例锚定分级尺度，输出格式约束能被程序解析——这正是第 3 章与第 5 章的组合应用。
第五步：用 Loop Engineering 让它持续运转
最后套上循环的外壳——状态文件 + 调度 + 人审门禁：
<!-- STATE.md：循环的记忆脊柱，每次运行后更新 -->
# Loop State — review-loop
Last run: 2026-08-22 08:00 UTC
## High Priority (等待人工)
- [ ] PR #1241 — 删除了输入校验 (blocker)
Loop action: 已生成审查意见，等待维护者确认
## Watch List
- PR #1238 已开启 4 天无活动
## Recent Noise (本轮忽略)
- Dependabot 依赖升级 PR（走独立自动化）# 每天早上 8 点调度（L1 报告模式起步）
# GitHub Actions cron: 0 8 * * 1-5
npx @cobusgreyling/loop init . --pattern daily-triage --tool claude
npx @cobusgreyling/loop doctor . # 健康检查：audit + 同步 → top 3 行动建议按照第 21 章的节奏推进：第一周 L1 只报告不自动修复 → 稳定后升 L2 允许起草小修复 → 经得起考验再考虑 L3 无人值守。
24.3 各层职责边界速查表
| 层 | 回答的问题 | 变更频率 | 失效症状 |
|---|---|---|---|
| 提示工程 | 单步怎么让模型做对 | 每次迭代都可能调 | 输出不稳定、格式跑偏 |
| MCP | 智能体能触达什么数据与动作 | 工具集变化时 | 智能体"看不见"PR/CI |
| Skills | 标准流程怎么沉淀复用 | 流程演进时 | 每次做法不一致 |
| AGENTS.md | 这个项目的规矩是什么 | 项目约定变化时 | 智能体违反团队规范 |
| Loop | 何时做、做多久、谁兜底 | 运行策略调整时 | 要么不动要么失控烧钱 |
排查口诀：做错了查提示，做不到查 MCP，做得乱查 Skill，不守规矩查 AGENTS.md，该动不动或停不下来查 Loop。
24.4 常见组合反模式
- 什么都塞进 AGENTS.md：常驻上下文被几百行规则淹没，模型反而抓不住重点——长流程应下沉为 Skill；
- 跳过 L1 直接 L3：没有报告期验证就无人值守，等于把生产仓库交给没人监督的实习生；
- 工具全靠裸拼 prompt：不用 MCP，在提示里粘贴 API 文档让模型猜调用方式——脆弱且浪费 token；
- STATE.md 无人维护：状态过期后循环基于错误记忆决策，比没有状态更危险（loop-sync 类工具就是防这个的）；
- 没有 human gate 的写操作：审查类循环可以只报告，但任何自动合并/部署动作必须有门禁与白名单（denylist / auto-merge allowlist）。
24.5 本章小结与后续路线
这门课带你打通了智能体系统的完整纵深：
- 01–09 章：掌握 Few-shot、CoT、ReAct、ToT 等提示技术，能防御提示注入；
- 10–15 章：理解并动手实现了 MCP Server，掌握了 Tools/Resources/Prompts 三大原语；
- 16–18 章：会用 Agent Skills 标准封装可复用能力并做团队治理；
- 19–22 章：理解循环的解剖结构与五大积木，能给项目做 Loop Ready 评估；
- 23–24 章：用 AGENTS.md 固化项目约定，并把五件套组合成持续运转的工作流。
接下来建议在本站继续深造：
| 方向 | 课程 | 关系 |
|---|---|---|
| 框架造智能体 | Agno | 用工业框架实现本课的手工循环：工具、记忆、Workflow 一应俱全 |
| 多智能体协作 | CrewAI | 把单个循环扩展为角色分工的团队 |
| 定制你的 harness | Pi | 本课 Skills/AGENTS.md 思想的终端实战版，还能写 TS 扩展 |
🧪 随堂测验
点击你认为正确的选项。答错时会展示正确答案与原因解析。
1. 在五件套架构中，"智能体看不到 CI 失败结果"最应该优先排查哪一层？
2. 为什么审查规则清单要做成 Skill 而不是写进 AGENTS.md？
3. 关于 Daily Triage 循环的上线路径，正确的是？
4. 发现循环连续三天基于过期的 STATE.md 做决策，这属于哪一层的问题？