1. 原问题与场景Coding Agent 跑 SDD 评审PRD 和 architecture.md 怎么交给另一个 AgentCoding Agent 跑规约驱动开发SDD时真正难的不是让某个 Agent 写出一版 PRD而是让另一个 Agent 或不同模型的 Agent 去交叉评审 PRD 和架构方案。你会在需求评审 4.1.5 和技术设计方案评审 4.2.4 反复遇到两个问题同一个项目里 Claude Code、Codex 等 Coding Agent 各配各的模型 Key切来切去容易乱长评审对话迅速把上下文窗口吃掉留给模型推理的空间不够评审质量下滑。我的做法是先把 TaoToken Key 创建好再把参与评审的 Coding Agent 的 Base URL 统一填成 https://taotoken.net/api让模型认证走 TaoToken 通道。这样同一把 Key 能在不同 Agent 间复用既保留不同模型看同一份设计的交叉验证思路又避免每个 Agent 单独配 Key、单独计费的碎片化。SDD 的需求评审和技术评审本质上是把“写”和“审”分开。写 PRD 的 Agent 容易沿着自己的假设补细节漏掉边界条件写架构的 Agent 容易把已经选定的技术栈当成唯一解。原文 4.1.5 和 4.2.4 都强调再找另一个 Agent 或不同模型的 Agent 来 review这个思路是对的。问题在于落地Claude Code 一套 KeyCodex 一套 Key第三个做仲裁的 Agent 又一套 Key切换供应商时还要改配置。评审对话一长上下文窗口被历史消息塞满模型留给推理的 Token 变少最后输出一堆不痛不痒的意见。1.1 需求评审 4.1.5为什么不能只让写作 Agent 自审需求阶段最怕的是“自己写自己审”。同一个 Agent 刚写完 docs/prd.md它已经接受了自己的假设再让它找问题它更倾向于润色措辞而不是推翻前提。更有效的做法是让一个独立评审 Agent 只读 PRD不看写作过程按逻辑一致性、歧义、冗余、可测试性、边界条件五个维度输出问题清单。评审 Agent 不需要知道你是怎么聊出来的它只需要看到最终文档和评审规则。这样输出的问题更接近真实评审会上的视角也更容易被产品、研发、测试三方对齐。但独立评审 Agent 一多Key 管理就变成杂活。Claude Code 要配 Anthropic 风格的 KeyCodex 要配 OpenAI 风格的 Key如果你还想换模型比如从 A 模型切到 B 模型又要改 Base URL 或供应商配置。评审流程本来应该关注 PRD 质量结果一半时间花在“这个 Agent 现在到底在用哪把 Key”。把模型认证统一到 TaoToken 后评审 Agent 只认一把 Key切换模型时改模型 ID 即可Base URL 保持 https://taotoken.net/api 不变流程会稳定很多。1.2 技术方案评审 4.2.4为什么不同模型看 architecture.md 更有价值技术设计方案评审比需求评审更依赖上下文。architecture.md 里通常包含分层、模块边界、接口定义、依赖方向、数据流、异常处理、部署约束。一个 Agent 写出来的架构往往会在自己熟悉的模式里打转比如把所有逻辑塞进 Service或者让接口承担过多字段。换一个不同模型的 Agent 去审它可能会从接口幂等、模块循环依赖、扩展点、安全边界这些角度提出不同问题。交叉评审的价值不是让两个模型投票而是让它们从不同盲区里捞问题。这里也最容易被上下文窗口反噬。技术评审对话里既有 PRD 摘要又有架构全文还有历史评审意见和你的追问。如果每一轮都把全部内容塞进去上下文很快被填满模型对中间部分的注意力下降出现“前面看过、后面忘了”的情况。原文 5.2 强调要留足推理空间落到操作上就是评审输入要精炼评审输出要结构化评审历史要及时 compact。多 Agent 评审 Harness 应该把“写”和“审”的会话隔离把“审”和“仲裁”的会话也隔离避免上下文互相污染。2. TaoToken 前置创建 Key把 Claude Code/Codex 的 Base URL 指向 https://taotoken.net/api先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建一把 TaoToken Key。创建完成后把 Key 放到环境变量里不要直接写进仓库文件。参与评审的 Coding Agent比如 Claude Code、Codex统一把模型请求的 Base URL 填成 https://taotoken.net/api认证使用同一把 TaoToken Key。这样需求评审 Agent 和技术评审 Agent 可以共用入口后续更换模型供应商时只改模型 ID 或评审配置不用重新给每个 Agent 配一套 Base URL。TaoToken 在这里承担的是统一模型接入入口的角色。你不需要在每个 Agent 里分别维护不同供应商的 Key也不需要因为某个 Agent 换了模型就把整套配置重写一遍。对于多 Agent 评审场景这一点很关键写 PRD 的 Agent、审 PRD 的 Agent、审架构的 Agent、做仲裁的 Agent可能来自不同 CLI、不同模型、不同会话但它们都可以通过 https://taotoken.net/api 这一个入口完成认证。Key 的管理、权限和后续替换都集中在一处排障时也更容易定位是 Key 问题、Base URL 问题还是模型名问题。2.1 一把 TaoToken Key 解决多 Agent Key 碎片化多 Agent 评审最容易乱的地方是配置漂移。Claude Code 的终端窗口里导出过一组环境变量Codex 的另一个窗口里可能还是旧 Key你换了模型只改了其中一个 Agent 的配置另一个 Agent 还在请求旧地址。更麻烦的是长评审对话里你很难判断某次输出质量下降是模型本身的问题还是认证通道不稳定、模型名不对、上下文过长。统一走 TaoToken 后至少认证入口和 Base URL 是一致的排障范围会缩小很多。具体收益可以拆成三点。第一同一把 Key 可以在 Claude Code、Codex 以及其他兼容 OpenAI 或 Anthropic 调用方式的 Agent 之间复用减少来回切换。第二评审 Agent 的配置文件可以模板化harness.sh 里只需要引用 TAOTOKEN_API_KEY不用为每个 CLI 写一套认证逻辑。第三切换模型时只改 REVIEW_MODEL 这类变量Base URL 保持 https://taotoken.net/api评审流程不会因为供应商变化而重配。对于 SDD 这种强调规约和可重复性的开发方式配置越集中越好。2.2 创建 Key 前的版本与环境检查在改配置前先确认本地 CLI 版本和已有环境变量。不同版本的 Claude Code、Codex 读取的变量名可能略有差异先看清楚再改比盲目复制配置更稳。下面命令只检查变量名是否存在不打印 Key 内容避免终端历史泄漏。which claude || true claude --version || true which codex || true codex --version || true node --version || true env | cut -d -f1 | grep -E ANTHROPIC|OPENAI|TAOTOKEN || true test -n ${TAOTOKEN_API_KEY:-} echo TAOTOKEN_API_KEY 已设置 || echo TAOTOKEN_API_KEY 未设置如果 TAOTOKEN_API_KEY 未设置先通过官网创建再继续下一步。如果你已经有旧 Key建议在控制台重新生成一把专用于多 Agent 评审的 Key方便后续区分用途。控制台入口可以走 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 接入细节看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。不要用生产环境的 Key 跑实验评审避免误操作影响其他任务。3. 可复制配置Claude Code 与 Codex 接入 TaoToken 通道、评审提示词和 harness.sh这一章是核心目标是把“另一个 Agent 来 review”从手动聊天变成可重复执行的流程。你需要三样东西统一的环境变量、每个 Agent 可读的评审提示词、一个把 producer 和 reviewer 串起来的 harness.sh。配置完成后Claude Code 可以审 PRDCodex 可以审 architecture.md第三个 Agent 可以合并两边结论。所有 Agent 的模型请求都走 https://taotoken.net/api认证都用 TAOTOKEN_API_KEY。先建一个最小目录把被评审文件和评审输出分开。不要把评审输出写回 docs/避免污染原始规约。建议结构如下sdd-review/ ├── docs/ │ ├── prd.md │ └── architecture.md ├── prompts/ │ ├── review_prd.md │ └── review_arch.md ├── reviews/ └── harness.sh3.1 Claude Code 环境变量配置Claude Code 通常读取 ANTHROPIC_BASE_URL 和认证相关变量。不同版本可能使用 ANTHROPIC_AUTH_TOKEN 或 ANTHROPIC_API_KEY建议两个都设置哪个生效就保留哪个。把下面内容放到 ~/.zshrc 或 ~/.bashrc然后重新打开终端或 source 一下。注意不要把你真实的 Key 提交到 Git也不要写进项目级 .env 后忘记加 .gitignore。export TAOTOKEN_API_KEY你的TaoTokenKey export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_API_KEY$TAOTOKEN_API_KEY claude --version如果 Claude Code 启动后仍然报认证错误先用最小请求确认通道可用而不是直接进入长评审。可以临时开一个干净终端只导出必要变量再运行一个短提示。短请求成功后再跑 PRD 评审能避免把认证问题和上下文问题混在一起排查。记住 Base URL 写 https://taotoken.net/api不要带 UTM 参数也不要额外拼 /v1除非你的接入文档明确要求。3.2 Codex config.toml 与环境变量配置Codex 这边建议同时准备环境变量和 config.toml。环境变量负责放 Key 和 Base URLconfig.toml 负责声明模型供应商和默认模型。下面示例中的模型名只是占位实际以你在 TaoToken 控制台看到的可用模型 ID 为准。如果你的 Codex 版本不支持 wire_api 或 model_provider按 codex --help 输出调整保留 base_url 和 env_key 这两个核心字段。export TAOTOKEN_API_KEY你的TaoTokenKey export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEYmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses改完后运行一个最小验证确认 Codex 能返回内容。不要一上来就让它读完整 architecture.md先用“只回复 ok”的提示确认认证和模型名。最小验证通过后再把模型换成评审专用模型或者在 harness.sh 里用 REVIEW_MODEL 控制。这样切换模型供应商时你只需要改 model 或 REVIEW_MODELBase URL 仍然是 https://taotoken.net/api。3.3 评审提示词模板让 Agent 输出可合并的问题清单评审 Agent 最容易输出“建议优化”“可以更清晰”这类废话。解决办法是在提示词里强制格式和证据。下面模板可以直接放进 prompts/review_prd.md技术评审模板把输入改成 architecture.md再增加接口、模块边界、依赖方向、性能和安全维度。每个问题必须有位置、证据、影响、建议方便你后面用第三个 Agent 合并去重。你是独立评审 Agent只做审查不修改文件。 输入 - PRDdocs/prd.md 评审维度 1. 逻辑一致性 2. 歧义与遗漏 3. 冗余功能 4. 可测试性与验收标准 5. 边界条件与异常路径 输出格式 每条问题包含 ID、严重级别 P0/P1/P2、位置、证据、影响、建议。 必须引用具体章节或原文片段禁止只写“建议优化”。技术评审模板可以再加一段“检查 architecture.md 与 prd.md 的一致性重点看接口定义、模块依赖方向、数据一致性、幂等、性能瓶颈、扩展点、安全边界。发现循环依赖、职责不清、抽象泄漏时给出重构建议。” 这样 Codex 审架构时不会只挑命名问题而会往真正的设计风险上走。3.4 harness.sh串起 producer、reviewer、arbiter 三个 Agent下面脚本把评审流程串起来。它先让 Claude Code 审 PRD再让 Codex 审 architecture.md最后让第三个 Claude Code 会话读取两份评审结果做合并。所有 Agent 共用 TAOTOKEN_API_KEY 和 https://taotoken.net/api。不同 Codex 版本的子命令可能不同如果 codex exec 不存在用 codex --help 找非交互执行参数核心是把提示词和输入文件传进去。#!/usr/bin/env bash set -euo pipefail export TAOTOKEN_API_KEY${TAOTOKEN_API_KEY:?请先设置 TAOTOKEN_API_KEY} export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_API_KEY$TAOTOKEN_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEY REVIEW_MODEL${REVIEW_MODEL:-gpt-5-codex} mkdir -p reviews claude -p 你是需求评审 Agent。读取 docs/prd.md按逻辑一致性、歧义、冗余、可测试性、边界条件输出问题清单。每条给位置、证据、影响和修改建议。只输出 Markdown。 reviews/prd_review_claude.md codex exec --model $REVIEW_MODEL 你是技术方案评审 Agent。读取 docs/architecture.md 和 docs/prd.md检查一致性、遗漏、接口设计、模块边界、依赖方向、性能、扩展性和安全风险。只输出 Markdown。 reviews/arch_review_codex.md claude -p 读取 reviews/prd_review_claude.md 和 reviews/arch_review_codex.md合并去重按 P0/P1/P2 排序生成 reviews/final_review.md。不要修改被评审文件只输出最终评审结论。 reviews/arbiter_notes.md跑之前先 chmod x。如果只验证一个 Agent可以注释掉其他行先确认 Claude Code 或 Codex 能单独返回。不要一上来就跑完整流水线否则 401、模型名错误、上下文溢出会混在一起。小步验证是排障成本最低的方式。3.5 上下文预算给评审留足推理空间原文 5.2 强调留足推理空间这件事在评审 Harness 里可以量化。不要把所有历史对话、全量 PRD、全量架构、所有旧评审意见一次性塞给模型。更稳的做法是给每类内容设预算规则固定且短输入只给相关章节输出预留足够 Token历史评审压缩成摘要。评审 Agent 的目标是发现问题不是复述文档。内容建议占用做法评审规则300-500 tokens固定模板不放历史对话PRD 输入1000-2000 tokens优先给变更章节和验收标准架构输入3000-6000 tokens按模块拆分评审避免全文反复塞输出预留4000 tokens 以上让模型有足够空间组织问题清单历史评审压缩后 1000 tokens 内用 /compact 或先摘要再喂Claude Code 里可以用 /compact 压缩当前会话用 /clear 清理已经完成的任务历史。Codex 侧则尽量为每个评审任务开新会话不要把上一个 Agent 的输出直接当成事实继续追问。你可以把评审输出文件作为“待合并材料”而不是把整个对话历史直接拼到下一个 Agent 的上下文里。这样既保留交叉验证又避免上下文污染。4. 验证请求与成功结果两个 Agent 交叉评审 prd.md、architecture.md避免 context_length_exceeded配置完成后先跑最小验证再跑完整评审。最小验证的目标是确认 Claude Code 和 Codex 都能通过 TaoToken 通道返回内容。你可以分别运行短提示例如让 Claude Code 只回复 ok让 Codex 只回复 ok。如果两个都正常再执行 harness.sh。成功后你会得到 reviews 目录下多个文件而不是一个混在一起的超长聊天记录。chmod x harness.sh export REVIEW_MODELgpt-5-codex ./harness.sh ls -lh reviews/4.1 运行 harness 并检查输出文件运行结束后先看文件是否生成再看内容是否结构化。评审输出不应该只有一段总结而应该有编号、严重级别、位置、证据和建议。你可以用 grep 快速检查是否出现认证错误、模型名错误或上下文超限错误。如果 grep 到 401、403、model_not_found、context_length_exceeded先处理错误不要急着看评审结论因为错误状态下的输出没有参考价值。ls -lh reviews/ grep -R 401\|403\|model_not_found\|context_length_exceeded reviews/ || \ echo 评审日志未发现认证、模型名和上下文错误如果一切正常reviews 目录应该类似这样reviews/prd_review_claude.md reviews/arch_review_codex.md reviews/final_review.md reviews/arbiter_notes.md4.2 成功结果长什么样成功的 PRD 评审会指出具体问题例如“PRD-003 用户注销后的数据保留周期未定义影响合规与存储设计建议补充默认保留天数和清理任务。”成功的架构评审会指出设计风险例如“ARCH-002 支付模块反向依赖订单模块建议通过事件或接口下沉解除循环依赖。”这些结论不是泛泛而谈而是能直接回到 PRD 或 architecture.md 修改的内容。我试过把 PRD 评审交给 Claude Code、架构评审交给 Codex最后让第三个 Agent 做仲裁关键不是模型谁更强而是每个评审会话独立输出格式固定合并时省很多时间。两个 Agent 都通过同一把 TaoToken Key 和 https://taotoken.net/api 访问模型切换模型时只改 REVIEW_MODEL。这样一来评审流程的重心回到文档质量而不是配置管理。4.3 让第三个 Agent 做仲裁与去重第三个 Agent 的职责不是重新评审而是合并两份评审结果。它要识别重复问题、冲突结论和优先级差异。比如 PRD 评审认为“验收标准缺失”是 P1架构评审认为同一问题导致“无法测试接口幂等”是 P0仲裁 Agent 应该合并成一条并提升优先级。仲裁提示词里要明确不要新增未经证据支持的问题只合并、去重、排序、标注来源。claude -p 读取 reviews/prd_review_claude.md 和 reviews/arch_review_codex.md。合并重复问题标注来源按 P0/P1/P2 排序。不要新增没有证据的问题。输出到 reviews/final_review.md。 reviews/arbiter_notes.md仲裁完成后你拿着 final_review.md 回到需求或架构文档逐条修改。修改后建议再跑一轮评审但不要复用旧会话。开新会话、重新喂修改后的相关章节能避免旧结论干扰新判断。SDD 的评审循环应该是“写、审、改、再审”而不是“一直在一个超长对话里聊到模型疲劳”。5. 本篇常见错排查401、404、模型名不存在、评审上下文溢出多 Agent 评审的报错通常集中在四类认证、地址、模型名、上下文。排查顺序建议从最小请求开始先确认单个 Agent 能通过 TaoToken 通道返回再扩大到多个 Agent。不要同时改环境变量、config.toml、提示词和 harness.sh否则你无法判断是哪一个改动导致失败。下面这些问题我都见过处理方式按优先级排列。5.1 401 与 Key 未生效401 通常表示 Key 没被正确读取或者认证变量名和 CLI 预期不一致。先确认当前终端里 Key 是否设置再确认你启动 Agent 的窗口是否继承了环境变量。如果你把 Key 写在 .env 文件里但 CLI 不会自动读取也会出现 401。不要在终端里直接 echo 完整 Key用 test 判断是否存在并检查变量名列表。test -n ${TAOTOKEN_API_KEY:-} echo TAOTOKEN_API_KEY exists env | cut -d -f1 | grep -E ANTHROPIC|OPENAI|TAOTOKEN如果 Claude Code 报 401确认 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 或 ANTHROPIC_API_KEY 是否都指向 TaoToken 配置。如果 Codex 报 401确认 OPENAI_API_KEY 是否等于 TAOTOKEN_API_KEY或者 config.toml 的 env_key 是否写成了 TAOTOKEN_API_KEY。修改后重开终端不要依赖旧会话。5.2 404 与 Base URL 拼接404 常见原因是 Base URL 多拼或少拼。参与评审的 Coding Agent 统一填 https://taotoken.net/api。不要在这个地址后面加 UTM 参数也不要随手加 /v1 或去掉 /api。SDK 或 CLI 可能会在内部拼接路径你手动改 Base URL 反而容易导致请求路径错误。如果某个工具文档明确要求 /v1以该工具的文档为准但在多 Agent 混用时先把所有工具统一到 https://taotoken.net/api再单独解决例外。echo $ANTHROPIC_BASE_URL echo $OPENAI_BASE_URL两个输出都应该是 https://taotoken.net/api。如果显示为空说明当前 shell 没加载配置如果显示旧地址说明你改了另一个终端的配置。把环境变量写进 shell 配置文件后重新打开终端或 source 对应文件。5.3 context_length_exceeded 与长对话清理context_length_exceeded 是评审阶段最隐蔽的问题。它不一定以报错形式出现有时表现为模型开始重复、遗漏、答非所问。处理方式是压缩和拆分Claude Code 里用 /compact 总结历史用 /clear 清空已完成任务Codex 里为每个评审任务开新会话。对于长文档先分模块评审再合并结论。不要把所有旧评审意见原样塞进下一轮。sed -n 1,120p docs/prd.md /tmp/prd_review_section.md sed -n 1,160p docs/architecture.md /tmp/arch_review_section.md评审完临时文件后可以删除。关键原则是输入给模型的材料要相关、精炼、有边界输出和推理要留空间。评审 Agent 需要思考不是只需要阅读。上下文被填满时它就没有足够 Token 做真正的比较和推理。5.4 模型名不存在与供应商切换模型名不存在通常是因为配置里的 model 和控制台可用模型 ID 不一致。处理方式是从控制台或接入文档确认可用模型 ID然后改 REVIEW_MODEL 或 config.toml 的 model。切换模型供应商时Base URL 保持 https://taotoken.net/api只改模型 ID。不要把旧模型名硬编码在多个脚本里统一用环境变量后续替换会轻松很多。export REVIEW_MODEL你在控制台看到的模型ID ./harness.sh如果你的 Codex 和 Claude Code 使用不同模型建议在 harness.sh 里分开变量例如 PRD_REVIEW_MODEL 和 ARCH_REVIEW_MODEL。这样需求评审和技术评审可以各用各的模型同时共用同一把 Key 和同一个 Base URL。5.5 评审结论互相污染多 Agent 评审最怕 A Agent 的输出影响 B Agent 的判断。正确做法是让每个评审 Agent 独立读原始文档输出到独立文件最后由仲裁 Agent 合并。不要让 Codex 直接读 Claude Code 的完整聊天记录也不要让第三个 Agent 在没有来源标注的情况下重写结论。输出文件里要保留问题 ID、来源、严重级别和证据这样后续修改和复查都有依据。仲裁时只合并事实和问题不要扩写新需求。修改 PRD 或 architecture.md 后重新开评审会话重新喂修改后的相关章节。旧评审结论可以作为 checklist但不要作为新会话的唯一输入。SDD 的价值在于规约可追踪评审可重复而不是让多个 Agent 在一个无限长的对话里互相说服。6. 语义一致 CTA把多 Agent SDD 评审流程接到 TaoToken API Keys 与 Coding Plan如果你已经在跑 Claude Code、Codex 或多 Agent 评审下一步最值得做的是把 Key 和 Base URL 固定下来。创建和管理 Key 走 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 接入排障和 Base URL 配置看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。需要单独验证某个模型是否可用可以用 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 做短请求测试不要直接拿长 PRD 做首次验证。如果你准备把多 Agent 评审长期纳入 SDD 流程建议走 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。控制台入口是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。Claude Code 相关接入说明可以看 https://taotoken.net/doc/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址统一用 https://taotoken.net/api。把 REVIEW_MODEL 固定成评审专用模型把 producer 和 reviewer 的会话分开再在每个评审任务后执行 compactSDD 评审就能从人肉切 Key 变成可重复流水线。
Coding Agent 跑 SDD 评审流程，Key 走 TaoToken 通道
1. 原问题与场景Coding Agent 跑 SDD 评审PRD 和 architecture.md 怎么交给另一个 AgentCoding Agent 跑规约驱动开发SDD时真正难的不是让某个 Agent 写出一版 PRD而是让另一个 Agent 或不同模型的 Agent 去交叉评审 PRD 和架构方案。你会在需求评审 4.1.5 和技术设计方案评审 4.2.4 反复遇到两个问题同一个项目里 Claude Code、Codex 等 Coding Agent 各配各的模型 Key切来切去容易乱长评审对话迅速把上下文窗口吃掉留给模型推理的空间不够评审质量下滑。我的做法是先把 TaoToken Key 创建好再把参与评审的 Coding Agent 的 Base URL 统一填成 https://taotoken.net/api让模型认证走 TaoToken 通道。这样同一把 Key 能在不同 Agent 间复用既保留不同模型看同一份设计的交叉验证思路又避免每个 Agent 单独配 Key、单独计费的碎片化。SDD 的需求评审和技术评审本质上是把“写”和“审”分开。写 PRD 的 Agent 容易沿着自己的假设补细节漏掉边界条件写架构的 Agent 容易把已经选定的技术栈当成唯一解。原文 4.1.5 和 4.2.4 都强调再找另一个 Agent 或不同模型的 Agent 来 review这个思路是对的。问题在于落地Claude Code 一套 KeyCodex 一套 Key第三个做仲裁的 Agent 又一套 Key切换供应商时还要改配置。评审对话一长上下文窗口被历史消息塞满模型留给推理的 Token 变少最后输出一堆不痛不痒的意见。1.1 需求评审 4.1.5为什么不能只让写作 Agent 自审需求阶段最怕的是“自己写自己审”。同一个 Agent 刚写完 docs/prd.md它已经接受了自己的假设再让它找问题它更倾向于润色措辞而不是推翻前提。更有效的做法是让一个独立评审 Agent 只读 PRD不看写作过程按逻辑一致性、歧义、冗余、可测试性、边界条件五个维度输出问题清单。评审 Agent 不需要知道你是怎么聊出来的它只需要看到最终文档和评审规则。这样输出的问题更接近真实评审会上的视角也更容易被产品、研发、测试三方对齐。但独立评审 Agent 一多Key 管理就变成杂活。Claude Code 要配 Anthropic 风格的 KeyCodex 要配 OpenAI 风格的 Key如果你还想换模型比如从 A 模型切到 B 模型又要改 Base URL 或供应商配置。评审流程本来应该关注 PRD 质量结果一半时间花在“这个 Agent 现在到底在用哪把 Key”。把模型认证统一到 TaoToken 后评审 Agent 只认一把 Key切换模型时改模型 ID 即可Base URL 保持 https://taotoken.net/api 不变流程会稳定很多。1.2 技术方案评审 4.2.4为什么不同模型看 architecture.md 更有价值技术设计方案评审比需求评审更依赖上下文。architecture.md 里通常包含分层、模块边界、接口定义、依赖方向、数据流、异常处理、部署约束。一个 Agent 写出来的架构往往会在自己熟悉的模式里打转比如把所有逻辑塞进 Service或者让接口承担过多字段。换一个不同模型的 Agent 去审它可能会从接口幂等、模块循环依赖、扩展点、安全边界这些角度提出不同问题。交叉评审的价值不是让两个模型投票而是让它们从不同盲区里捞问题。这里也最容易被上下文窗口反噬。技术评审对话里既有 PRD 摘要又有架构全文还有历史评审意见和你的追问。如果每一轮都把全部内容塞进去上下文很快被填满模型对中间部分的注意力下降出现“前面看过、后面忘了”的情况。原文 5.2 强调要留足推理空间落到操作上就是评审输入要精炼评审输出要结构化评审历史要及时 compact。多 Agent 评审 Harness 应该把“写”和“审”的会话隔离把“审”和“仲裁”的会话也隔离避免上下文互相污染。2. TaoToken 前置创建 Key把 Claude Code/Codex 的 Base URL 指向 https://taotoken.net/api先打开 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建一把 TaoToken Key。创建完成后把 Key 放到环境变量里不要直接写进仓库文件。参与评审的 Coding Agent比如 Claude Code、Codex统一把模型请求的 Base URL 填成 https://taotoken.net/api认证使用同一把 TaoToken Key。这样需求评审 Agent 和技术评审 Agent 可以共用入口后续更换模型供应商时只改模型 ID 或评审配置不用重新给每个 Agent 配一套 Base URL。TaoToken 在这里承担的是统一模型接入入口的角色。你不需要在每个 Agent 里分别维护不同供应商的 Key也不需要因为某个 Agent 换了模型就把整套配置重写一遍。对于多 Agent 评审场景这一点很关键写 PRD 的 Agent、审 PRD 的 Agent、审架构的 Agent、做仲裁的 Agent可能来自不同 CLI、不同模型、不同会话但它们都可以通过 https://taotoken.net/api 这一个入口完成认证。Key 的管理、权限和后续替换都集中在一处排障时也更容易定位是 Key 问题、Base URL 问题还是模型名问题。2.1 一把 TaoToken Key 解决多 Agent Key 碎片化多 Agent 评审最容易乱的地方是配置漂移。Claude Code 的终端窗口里导出过一组环境变量Codex 的另一个窗口里可能还是旧 Key你换了模型只改了其中一个 Agent 的配置另一个 Agent 还在请求旧地址。更麻烦的是长评审对话里你很难判断某次输出质量下降是模型本身的问题还是认证通道不稳定、模型名不对、上下文过长。统一走 TaoToken 后至少认证入口和 Base URL 是一致的排障范围会缩小很多。具体收益可以拆成三点。第一同一把 Key 可以在 Claude Code、Codex 以及其他兼容 OpenAI 或 Anthropic 调用方式的 Agent 之间复用减少来回切换。第二评审 Agent 的配置文件可以模板化harness.sh 里只需要引用 TAOTOKEN_API_KEY不用为每个 CLI 写一套认证逻辑。第三切换模型时只改 REVIEW_MODEL 这类变量Base URL 保持 https://taotoken.net/api评审流程不会因为供应商变化而重配。对于 SDD 这种强调规约和可重复性的开发方式配置越集中越好。2.2 创建 Key 前的版本与环境检查在改配置前先确认本地 CLI 版本和已有环境变量。不同版本的 Claude Code、Codex 读取的变量名可能略有差异先看清楚再改比盲目复制配置更稳。下面命令只检查变量名是否存在不打印 Key 内容避免终端历史泄漏。which claude || true claude --version || true which codex || true codex --version || true node --version || true env | cut -d -f1 | grep -E ANTHROPIC|OPENAI|TAOTOKEN || true test -n ${TAOTOKEN_API_KEY:-} echo TAOTOKEN_API_KEY 已设置 || echo TAOTOKEN_API_KEY 未设置如果 TAOTOKEN_API_KEY 未设置先通过官网创建再继续下一步。如果你已经有旧 Key建议在控制台重新生成一把专用于多 Agent 评审的 Key方便后续区分用途。控制台入口可以走 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 接入细节看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。不要用生产环境的 Key 跑实验评审避免误操作影响其他任务。3. 可复制配置Claude Code 与 Codex 接入 TaoToken 通道、评审提示词和 harness.sh这一章是核心目标是把“另一个 Agent 来 review”从手动聊天变成可重复执行的流程。你需要三样东西统一的环境变量、每个 Agent 可读的评审提示词、一个把 producer 和 reviewer 串起来的 harness.sh。配置完成后Claude Code 可以审 PRDCodex 可以审 architecture.md第三个 Agent 可以合并两边结论。所有 Agent 的模型请求都走 https://taotoken.net/api认证都用 TAOTOKEN_API_KEY。先建一个最小目录把被评审文件和评审输出分开。不要把评审输出写回 docs/避免污染原始规约。建议结构如下sdd-review/ ├── docs/ │ ├── prd.md │ └── architecture.md ├── prompts/ │ ├── review_prd.md │ └── review_arch.md ├── reviews/ └── harness.sh3.1 Claude Code 环境变量配置Claude Code 通常读取 ANTHROPIC_BASE_URL 和认证相关变量。不同版本可能使用 ANTHROPIC_AUTH_TOKEN 或 ANTHROPIC_API_KEY建议两个都设置哪个生效就保留哪个。把下面内容放到 ~/.zshrc 或 ~/.bashrc然后重新打开终端或 source 一下。注意不要把你真实的 Key 提交到 Git也不要写进项目级 .env 后忘记加 .gitignore。export TAOTOKEN_API_KEY你的TaoTokenKey export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_API_KEY$TAOTOKEN_API_KEY claude --version如果 Claude Code 启动后仍然报认证错误先用最小请求确认通道可用而不是直接进入长评审。可以临时开一个干净终端只导出必要变量再运行一个短提示。短请求成功后再跑 PRD 评审能避免把认证问题和上下文问题混在一起排查。记住 Base URL 写 https://taotoken.net/api不要带 UTM 参数也不要额外拼 /v1除非你的接入文档明确要求。3.2 Codex config.toml 与环境变量配置Codex 这边建议同时准备环境变量和 config.toml。环境变量负责放 Key 和 Base URLconfig.toml 负责声明模型供应商和默认模型。下面示例中的模型名只是占位实际以你在 TaoToken 控制台看到的可用模型 ID 为准。如果你的 Codex 版本不支持 wire_api 或 model_provider按 codex --help 输出调整保留 base_url 和 env_key 这两个核心字段。export TAOTOKEN_API_KEY你的TaoTokenKey export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEYmodel gpt-5-codex model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api responses改完后运行一个最小验证确认 Codex 能返回内容。不要一上来就让它读完整 architecture.md先用“只回复 ok”的提示确认认证和模型名。最小验证通过后再把模型换成评审专用模型或者在 harness.sh 里用 REVIEW_MODEL 控制。这样切换模型供应商时你只需要改 model 或 REVIEW_MODELBase URL 仍然是 https://taotoken.net/api。3.3 评审提示词模板让 Agent 输出可合并的问题清单评审 Agent 最容易输出“建议优化”“可以更清晰”这类废话。解决办法是在提示词里强制格式和证据。下面模板可以直接放进 prompts/review_prd.md技术评审模板把输入改成 architecture.md再增加接口、模块边界、依赖方向、性能和安全维度。每个问题必须有位置、证据、影响、建议方便你后面用第三个 Agent 合并去重。你是独立评审 Agent只做审查不修改文件。 输入 - PRDdocs/prd.md 评审维度 1. 逻辑一致性 2. 歧义与遗漏 3. 冗余功能 4. 可测试性与验收标准 5. 边界条件与异常路径 输出格式 每条问题包含 ID、严重级别 P0/P1/P2、位置、证据、影响、建议。 必须引用具体章节或原文片段禁止只写“建议优化”。技术评审模板可以再加一段“检查 architecture.md 与 prd.md 的一致性重点看接口定义、模块依赖方向、数据一致性、幂等、性能瓶颈、扩展点、安全边界。发现循环依赖、职责不清、抽象泄漏时给出重构建议。” 这样 Codex 审架构时不会只挑命名问题而会往真正的设计风险上走。3.4 harness.sh串起 producer、reviewer、arbiter 三个 Agent下面脚本把评审流程串起来。它先让 Claude Code 审 PRD再让 Codex 审 architecture.md最后让第三个 Claude Code 会话读取两份评审结果做合并。所有 Agent 共用 TAOTOKEN_API_KEY 和 https://taotoken.net/api。不同 Codex 版本的子命令可能不同如果 codex exec 不存在用 codex --help 找非交互执行参数核心是把提示词和输入文件传进去。#!/usr/bin/env bash set -euo pipefail export TAOTOKEN_API_KEY${TAOTOKEN_API_KEY:?请先设置 TAOTOKEN_API_KEY} export ANTHROPIC_BASE_URLhttps://taotoken.net/api export ANTHROPIC_AUTH_TOKEN$TAOTOKEN_API_KEY export ANTHROPIC_API_KEY$TAOTOKEN_API_KEY export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY$TAOTOKEN_API_KEY REVIEW_MODEL${REVIEW_MODEL:-gpt-5-codex} mkdir -p reviews claude -p 你是需求评审 Agent。读取 docs/prd.md按逻辑一致性、歧义、冗余、可测试性、边界条件输出问题清单。每条给位置、证据、影响和修改建议。只输出 Markdown。 reviews/prd_review_claude.md codex exec --model $REVIEW_MODEL 你是技术方案评审 Agent。读取 docs/architecture.md 和 docs/prd.md检查一致性、遗漏、接口设计、模块边界、依赖方向、性能、扩展性和安全风险。只输出 Markdown。 reviews/arch_review_codex.md claude -p 读取 reviews/prd_review_claude.md 和 reviews/arch_review_codex.md合并去重按 P0/P1/P2 排序生成 reviews/final_review.md。不要修改被评审文件只输出最终评审结论。 reviews/arbiter_notes.md跑之前先 chmod x。如果只验证一个 Agent可以注释掉其他行先确认 Claude Code 或 Codex 能单独返回。不要一上来就跑完整流水线否则 401、模型名错误、上下文溢出会混在一起。小步验证是排障成本最低的方式。3.5 上下文预算给评审留足推理空间原文 5.2 强调留足推理空间这件事在评审 Harness 里可以量化。不要把所有历史对话、全量 PRD、全量架构、所有旧评审意见一次性塞给模型。更稳的做法是给每类内容设预算规则固定且短输入只给相关章节输出预留足够 Token历史评审压缩成摘要。评审 Agent 的目标是发现问题不是复述文档。内容建议占用做法评审规则300-500 tokens固定模板不放历史对话PRD 输入1000-2000 tokens优先给变更章节和验收标准架构输入3000-6000 tokens按模块拆分评审避免全文反复塞输出预留4000 tokens 以上让模型有足够空间组织问题清单历史评审压缩后 1000 tokens 内用 /compact 或先摘要再喂Claude Code 里可以用 /compact 压缩当前会话用 /clear 清理已经完成的任务历史。Codex 侧则尽量为每个评审任务开新会话不要把上一个 Agent 的输出直接当成事实继续追问。你可以把评审输出文件作为“待合并材料”而不是把整个对话历史直接拼到下一个 Agent 的上下文里。这样既保留交叉验证又避免上下文污染。4. 验证请求与成功结果两个 Agent 交叉评审 prd.md、architecture.md避免 context_length_exceeded配置完成后先跑最小验证再跑完整评审。最小验证的目标是确认 Claude Code 和 Codex 都能通过 TaoToken 通道返回内容。你可以分别运行短提示例如让 Claude Code 只回复 ok让 Codex 只回复 ok。如果两个都正常再执行 harness.sh。成功后你会得到 reviews 目录下多个文件而不是一个混在一起的超长聊天记录。chmod x harness.sh export REVIEW_MODELgpt-5-codex ./harness.sh ls -lh reviews/4.1 运行 harness 并检查输出文件运行结束后先看文件是否生成再看内容是否结构化。评审输出不应该只有一段总结而应该有编号、严重级别、位置、证据和建议。你可以用 grep 快速检查是否出现认证错误、模型名错误或上下文超限错误。如果 grep 到 401、403、model_not_found、context_length_exceeded先处理错误不要急着看评审结论因为错误状态下的输出没有参考价值。ls -lh reviews/ grep -R 401\|403\|model_not_found\|context_length_exceeded reviews/ || \ echo 评审日志未发现认证、模型名和上下文错误如果一切正常reviews 目录应该类似这样reviews/prd_review_claude.md reviews/arch_review_codex.md reviews/final_review.md reviews/arbiter_notes.md4.2 成功结果长什么样成功的 PRD 评审会指出具体问题例如“PRD-003 用户注销后的数据保留周期未定义影响合规与存储设计建议补充默认保留天数和清理任务。”成功的架构评审会指出设计风险例如“ARCH-002 支付模块反向依赖订单模块建议通过事件或接口下沉解除循环依赖。”这些结论不是泛泛而谈而是能直接回到 PRD 或 architecture.md 修改的内容。我试过把 PRD 评审交给 Claude Code、架构评审交给 Codex最后让第三个 Agent 做仲裁关键不是模型谁更强而是每个评审会话独立输出格式固定合并时省很多时间。两个 Agent 都通过同一把 TaoToken Key 和 https://taotoken.net/api 访问模型切换模型时只改 REVIEW_MODEL。这样一来评审流程的重心回到文档质量而不是配置管理。4.3 让第三个 Agent 做仲裁与去重第三个 Agent 的职责不是重新评审而是合并两份评审结果。它要识别重复问题、冲突结论和优先级差异。比如 PRD 评审认为“验收标准缺失”是 P1架构评审认为同一问题导致“无法测试接口幂等”是 P0仲裁 Agent 应该合并成一条并提升优先级。仲裁提示词里要明确不要新增未经证据支持的问题只合并、去重、排序、标注来源。claude -p 读取 reviews/prd_review_claude.md 和 reviews/arch_review_codex.md。合并重复问题标注来源按 P0/P1/P2 排序。不要新增没有证据的问题。输出到 reviews/final_review.md。 reviews/arbiter_notes.md仲裁完成后你拿着 final_review.md 回到需求或架构文档逐条修改。修改后建议再跑一轮评审但不要复用旧会话。开新会话、重新喂修改后的相关章节能避免旧结论干扰新判断。SDD 的评审循环应该是“写、审、改、再审”而不是“一直在一个超长对话里聊到模型疲劳”。5. 本篇常见错排查401、404、模型名不存在、评审上下文溢出多 Agent 评审的报错通常集中在四类认证、地址、模型名、上下文。排查顺序建议从最小请求开始先确认单个 Agent 能通过 TaoToken 通道返回再扩大到多个 Agent。不要同时改环境变量、config.toml、提示词和 harness.sh否则你无法判断是哪一个改动导致失败。下面这些问题我都见过处理方式按优先级排列。5.1 401 与 Key 未生效401 通常表示 Key 没被正确读取或者认证变量名和 CLI 预期不一致。先确认当前终端里 Key 是否设置再确认你启动 Agent 的窗口是否继承了环境变量。如果你把 Key 写在 .env 文件里但 CLI 不会自动读取也会出现 401。不要在终端里直接 echo 完整 Key用 test 判断是否存在并检查变量名列表。test -n ${TAOTOKEN_API_KEY:-} echo TAOTOKEN_API_KEY exists env | cut -d -f1 | grep -E ANTHROPIC|OPENAI|TAOTOKEN如果 Claude Code 报 401确认 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN 或 ANTHROPIC_API_KEY 是否都指向 TaoToken 配置。如果 Codex 报 401确认 OPENAI_API_KEY 是否等于 TAOTOKEN_API_KEY或者 config.toml 的 env_key 是否写成了 TAOTOKEN_API_KEY。修改后重开终端不要依赖旧会话。5.2 404 与 Base URL 拼接404 常见原因是 Base URL 多拼或少拼。参与评审的 Coding Agent 统一填 https://taotoken.net/api。不要在这个地址后面加 UTM 参数也不要随手加 /v1 或去掉 /api。SDK 或 CLI 可能会在内部拼接路径你手动改 Base URL 反而容易导致请求路径错误。如果某个工具文档明确要求 /v1以该工具的文档为准但在多 Agent 混用时先把所有工具统一到 https://taotoken.net/api再单独解决例外。echo $ANTHROPIC_BASE_URL echo $OPENAI_BASE_URL两个输出都应该是 https://taotoken.net/api。如果显示为空说明当前 shell 没加载配置如果显示旧地址说明你改了另一个终端的配置。把环境变量写进 shell 配置文件后重新打开终端或 source 对应文件。5.3 context_length_exceeded 与长对话清理context_length_exceeded 是评审阶段最隐蔽的问题。它不一定以报错形式出现有时表现为模型开始重复、遗漏、答非所问。处理方式是压缩和拆分Claude Code 里用 /compact 总结历史用 /clear 清空已完成任务Codex 里为每个评审任务开新会话。对于长文档先分模块评审再合并结论。不要把所有旧评审意见原样塞进下一轮。sed -n 1,120p docs/prd.md /tmp/prd_review_section.md sed -n 1,160p docs/architecture.md /tmp/arch_review_section.md评审完临时文件后可以删除。关键原则是输入给模型的材料要相关、精炼、有边界输出和推理要留空间。评审 Agent 需要思考不是只需要阅读。上下文被填满时它就没有足够 Token 做真正的比较和推理。5.4 模型名不存在与供应商切换模型名不存在通常是因为配置里的 model 和控制台可用模型 ID 不一致。处理方式是从控制台或接入文档确认可用模型 ID然后改 REVIEW_MODEL 或 config.toml 的 model。切换模型供应商时Base URL 保持 https://taotoken.net/api只改模型 ID。不要把旧模型名硬编码在多个脚本里统一用环境变量后续替换会轻松很多。export REVIEW_MODEL你在控制台看到的模型ID ./harness.sh如果你的 Codex 和 Claude Code 使用不同模型建议在 harness.sh 里分开变量例如 PRD_REVIEW_MODEL 和 ARCH_REVIEW_MODEL。这样需求评审和技术评审可以各用各的模型同时共用同一把 Key 和同一个 Base URL。5.5 评审结论互相污染多 Agent 评审最怕 A Agent 的输出影响 B Agent 的判断。正确做法是让每个评审 Agent 独立读原始文档输出到独立文件最后由仲裁 Agent 合并。不要让 Codex 直接读 Claude Code 的完整聊天记录也不要让第三个 Agent 在没有来源标注的情况下重写结论。输出文件里要保留问题 ID、来源、严重级别和证据这样后续修改和复查都有依据。仲裁时只合并事实和问题不要扩写新需求。修改 PRD 或 architecture.md 后重新开评审会话重新喂修改后的相关章节。旧评审结论可以作为 checklist但不要作为新会话的唯一输入。SDD 的价值在于规约可追踪评审可重复而不是让多个 Agent 在一个无限长的对话里互相说服。6. 语义一致 CTA把多 Agent SDD 评审流程接到 TaoToken API Keys 与 Coding Plan如果你已经在跑 Claude Code、Codex 或多 Agent 评审下一步最值得做的是把 Key 和 Base URL 固定下来。创建和管理 Key 走 https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 接入排障和 Base URL 配置看 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。需要单独验证某个模型是否可用可以用 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 做短请求测试不要直接拿长 PRD 做首次验证。如果你准备把多 Agent 评审长期纳入 SDD 流程建议走 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。控制台入口是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。Claude Code 相关接入说明可以看 https://taotoken.net/doc/claude-code-anthropic?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_agent_sdd_reviewutm_campaignrewrite 。官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址统一用 https://taotoken.net/api。把 REVIEW_MODEL 固定成评审专用模型把 producer 和 reviewer 的会话分开再在每个评审任务后执行 compactSDD 评审就能从人肉切 Key 变成可重复流水线。