FRD 编排与 MCP：针对代理的确定性上下文控制（无漂移）
I’m sorry, but I don’t have the ability to retrieve or view the content from external links. If you can provide the text you’d like translated, I’ll be happy to translate it into Simplified Chinese while preserving the formatting and technical terms as requested.
介绍
不久前，我写了一篇文章，解释了编排多个功能需求文档（FRD）的价值，以便在从头一步步构建 NestJS 样板时保持完全控制。
- FRD‑00：编排
- FRD‑01：骨架
- FRD‑02：ORM + 迁移
- FRD‑03：认证 + JWT
- FRD‑04：单元测试
它起作用了，但出现了一个经典问题：当 FRD 作为工作区中的“松散”文件存在时，代理可能读取错误的 .md，混淆阶段，或缓存错误的上下文。
之前
FRDs as files inside a folder → the agent might read the wrong document / mix phases / cache context.之后
MCP 工具 get_frd("00".."04") 根据 ID 返回正确的 FRD → 阶段受控的委派，减少漂移，提升可重复性。
文件基于上下文的薄弱点
在前面的文章中，我展示了使用 FRD 引导代理构建样板代码的好处。工作区的结构如下：
folder name: api-products
├─ FRD-00-master-orchestration.md
├─ FRD-01-boilerplate-core-products.md
├─ FRD-02-products-database.md
├─ FRD-03-auth-security.md
├─ FRD-04-unit-testing.md
└─ Start the orchestration..即使 FRD‑00 已经定义了顺序并委派了每个阶段，薄弱点仍然存在：工作区内的文件选择。
代理在使用基于文件的上下文时的典型失误：
- 读取错误的
.md文件。 - 阶段混淆（跳过步骤）。
- 在目标文件夹之外运行命令。
- 步骤非确定性。
解决方案：通过 MCP 实现确定性检索
什么是 MCP？
Model Context Protocol（MCP）是一种协议，允许你向代理/IDE 暴露工具（函数），使其能够以受控的方式请求信息，而不是通过读取工作区文件来“猜测”。
与其“搜索文件”，代理通过工具精确请求它所需的文档：
get_frd("00") → main orchestration
get_frd("01") → phase 1
get_frd("02") → phase 2
get_frd("03") → phase 3
get_frd("04") → phase 4结果
编排不再依赖于代理的“文件挑选”。在每个阶段，代理按正确的顺序请求相应的 FRD。规范输入是稳定的，因此两次独立运行往往会产生相同的结果。
可以强制执行的策略示例：
- “除非 FRD‑02 已完成，否则不能请求 FRD‑03。”
- “始终在请求其他任何 FRD 之前先请求 FRD‑00。”
在 VS Code 中，打开 MCP Servers 视图，确认 frd-orchestrator 已激活。
MCP 服务器配置
// .vscode/mcp.json
{
"servers": {
"frd-orchestrator": {
"type": "stdio",
"command": "/Users/jorgegomez/.local/bin/uv",
"args": ["run", "main.py"]
}
}
}注意： 在我的机器上，
uv位于/Users/jorgegomez/.local/bin/uv。请根据你的环境自行调整路径。
当服务器启动时，VS Code 控制台会显示 MCP 服务器正在运行。
示例交互
每个阶段都会触发 get_frd("0X")，服务器通过从磁盘读取相应文件来响应。
[FRD-Orchestrator] get_frd tool requested with frd_id=02
Reading FRD from disk: .../frd/FRD-02-products-database.md
[FRD-Orchestrator] get_frd tool requested with frd_id=03
Reading FRD from disk: .../frd/FRD-03-auth-security.md
[FRD-Orchestrator] get_frd tool requested with frd_id=04
Reading FRD from disk: .../frd/FRD-04-unit-testing.md显式的工具调用取代了“自由形式”的工作区读取。使用 MCP 后，上下文不再是“工作区探索”，而是“受控检索”，从而降低错误、加快编排速度，并使流程可复现。
大规模收益
该方法在企业环境中具有可扩展性。使用 MCP，AI 不再是“仅仅聊天”，而是成为一个受控组件，用于自动化任务、流程和工作流，使其与每个公司的业务逻辑保持一致。这是开发者今天应该走的方向：AI + 确定性工具 + 可复现的流程.
征求反馈
如果你看到这里，我很希望你能审阅这个方法并分享你的想法。我完全欢迎反馈、批评以及改进建议——无论是关于 FRD 设计还是 MCP 实现。如果你发现有什么可以更简洁、更安全或更易复现的地方，请在评论中告诉我。