Skip to content
SprintLoop / docs

AI SDLC 与 Context Engine

我们让 agent 跑生产代码的最初六个月，失败模式不是幻觉，而是健忘。同一个模型会在第八周提出第三周就已被拒掉的同一个方案。它会去用上一季度团队已经迁离的那个 deprecated API。它会因为 prompt 没带上真正的风格规范而凭空发明一个内部约定。这些都不是模型质量问题，是上下文问题。

Context Engine 是 SprintLoop 给出的答案：一个五维分层上下文包，跟随每次 agent dispatch 一起出发，policy 不过就拒绝出发，并且从每条关闭的 lane 中学习。

五个维度

一次 SprintLoop dispatch 携带一个 BMAD 包（Brief, Memory, Architecture, Decisions —— 实际是五个维度，但这个缩写比加进 Style 还早，沿用了下来）。各维度：

维度它捕获什么它住在哪
Product用户向功能规格、验收标准、边界用例关联的 Issue、lane brief、产品 wiki
System架构图、仓库结构、服务边界、所属关系从仓库自动抽取 + 手动编辑
Style编码规范、命名、错误处理、日志格式仓库的 .sprintloop/style.md + linter 配置
Policy硬性规则——安全、合规、deprecated API、禁用依赖工作区 policy 文件，所有者签名
Memory历史 lane 结果、被拒的方案、被接受的 pattern从已关闭 lane + sign-off 备注自动派生

每个维度通过不同机制喂给被 dispatch 的 agent。Product 和 System 通常进 system prompt。Style 作为一个工具提供，agent 可以查询（style.lookup("error handling for HTTP clients")）。Policy 在 dispatch 前和每次 tool 调用时被强制执行。Memory 通过向量检索按需取出。

一次 dispatch 怎么组装这个包

你点 Dispatch 时，工作区会跑一次 context build：

  1. 拉 Product。 lane brief，加上任何关联 Issue 的验收标准，加上 dispatcher 显式附加的参考文档。
  2. 拉 System。 每次 push 都会抽取一份仓库结构图；dispatch 取走与本 lane 作用域 claim 相关的那一片。如果 agent 要碰 apps/api/auth/**，它得到的是 auth 服务的目录树、所属标签和直接依赖——不是整个 monorepo。
  3. 拉 Style。 .sprintloop/style.md 里的内容，加上从 .eslintrc、.prettierrc、pyproject.toml 等抽出的配置。
  4. 拉 Policy。 总是。没有 opt-out。policy 违规会让 dispatch 在花掉任何一个 token 之前就中止。
  5. 拉 Memory。 对碰过重叠路径、或使用重叠语言的已关闭 lane 做一次向量检索。默认限定在最近 90 天；每个工作区可调。

这个包会被签名后挂到 lane 的起始条目上。lane 关闭时，你可以打开这个包，准确看到 agent 当时手上有什么材料。

Policy：硬失败

大多数维度是建议性的。Policy 不是。

policy 文件长这样——是一个医疗客户的真实片段：

.sprintloop/policy.yaml
forbid:
  - paths: ["src/lib/legacyAuth/**"]
    reason: "Legacy auth path; rewrite blocked until migration finishes 2026-Q2"
  - dependencies: ["moment", "request"]
    reason: "Banned: replace with date-fns / native fetch"
require:
  - test_coverage_delta: ">= 0"
  - reviewer: "security"
    on_paths: ["**/auth/**", "**/billing/**"]

当一次 dispatch 的包构造命中某条 policy 子句，按子句类型会发生两件事：

  • Pre-dispatch 硬失败。 明显会被 brief 触发的 forbid.paths 或 forbid.dependencies 子句会立刻中止 dispatch。dispatcher 看到一条横幅写明规则与原因；没有任何 token 被花掉。
  • 运行时硬失败。 harness 仍可以尝试——它在读到具体文件之前未必知道 policy 对这文件适用。当它试图写一个被禁路径时，存储层会返回 POLICY_DENIED 并附上规则名。agent 在自己的 tool log 里看到拒绝，要么改道、要么卡住。
  • Sign-off 硬失败。 require.reviewer: "security" 强制要求一名安全 reviewer（人或 agent）在 lane 关闭前完成 sign-off。没有例外路径。merge 按钮保持禁用。

policy 之所以是唯一一种硬失败维度，原因是监管：处于 SOC 2 / HIPAA / PCI 范围内的工作区，不能拥有”建议性”的规则——因为那种规则 agent 总能说服自己绕过。如果你的 policy 写”未经 security reviewer 不许碰 billing”，系统就会机械地强制执行。

Memory：学习如何复利

随时间最有意思的维度是 Memory。每条关闭的 lane 都会把若干信号写回工作区的 memory 存储：

  • 被批准的 pattern。 lane 出产的、被 reviewer 签字放行的代码，被嵌入用于检索。
  • 被拒绝的方案。 “能跑，但我们这边不这么做”这类 sign-off 备注成为负样本。
  • 失败的假设。 当 agent 对代码库猜错、被人类纠正时，纠正被存为 Q&A 对。
  • 领域词汇。 团队领域里那些不会出现在任何公开训练集中的名字、缩写、行话。

Memory 检索按工作区作用域，不会跨客户泄漏，并用工作区自有的 key 做静态加密。

复利效应真实但缓慢——大约要三到四周的活跃使用，你才会看到 agent 不再犯同一个错。你能直接看到的信号是：每条关闭 lane 上的 Memory tab 显示这次 dispatch 取回了哪些过去的 lane，diff 页面则显示 agent 在 commit message 里引用了哪几条 Memory 条目。

编辑这个包

你可以直接从 dispatch 对话框编辑这个包：点 Inspect bundle，看一眼组装好的 prompt 与 tool spec，对任意维度做内联编辑，保存并 dispatch。编辑作用于单次 dispatch——不会改变底层 source。如果想做永久修改，请去改 .sprintloop/style.md、policy 文件、系统结构图等等，然后重新抽取。

Inspect bundle 视图也是 debug 一次行为奇怪 dispatch 的最快路径。如果 agent 去用 deprecated API，多半是因为包里没带上禁它的 policy。如果 agent 凭空发明 style 规范，那是包里的 Style 维度太薄。包是真相，agent 行为是下游。

接下来是什么

Context Engine 是 SprintLoop dispatch 做出好决策的其中一半。另一半是 Review Committee —— 在 diff 抵达人类之前给它打分的 reviewer agent 面板。