AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载导读本文围绕 ouroboros 项目中已评审通过的 RFC interview-hardening.md 展开系统讲解其三项核心加固提升访谈Interview阶段单条回答与整体提示的字符预算、在 skills/interview/SKILL.md 中落地 Refine精炼确认与 Restate一句话复述两道关卡、以及在嵌套 MCP 访谈入口强制开启strict_mcp_config适配器隔离以防止 ouroboros MCP 服务自递归启动。读完本文你将掌握 ouroboros 访谈管道防止静默截断、防止单行答案压缩、防止自我递归的完整原理、配置参数演进与对应的源码与测试证据可直接用于排查“访谈第三轮挂起”“下一问总是停留在标签确认”等实际问题。1. RFC 定位一次观察驱动三项独立加固1.1 状态与落地方式该 RFC 状态为Accepted2026-05-11由三个相互独立、可分别合并的 PR 实施PR分支内容#822feat/interview-adapter-isolation适配器隔离嵌套 MCP 边界显式请求strict_mcp_configTrue#823feat/interview-prompt-cap-raise提示预算提升单条回答与总提示字符上限#824feat/interview-refine-restateRefine/Restate 关卡写入skills/interview/SKILL.md三个 PR 动机一致均源自一个底层观察访谈 LLM 是一个不带任何工具的问题生成器question generator主会话main session是通向它的唯一上下文通道。任何丢弃、压缩或递归重生成上下文的操作都会劣化访谈的苏格拉底式提问质量。1.2 范围说明Scope NoteRFC 中第 3 项变更在合并实现时有一个重要范围收敛strict_mcp_configTrue只应用于嵌套 MCP 处理句柄边界src/ouroboros/mcp/tools/authoring_handlers.py 中的InterviewHandler而非全局默认开启于InterviewEngine.__post_init__。CLI 与 PM 访谈入口ooo init/ooo pm保留原有的插件/项目.mcp.json行为对这些入口启用更严格默认策略需等待 MCP 宿主之外的自我生成self-spawn实证测量后另行跟进。这一范围说明在当前源码中依然成立下文第 4 节会给出代码级印证。2. 背景访谈是主会话的提问而不是 LLM 的提问RFC 明确指出commands/interview.md与 skills/interview/SKILL.md 已确立访谈 MCP 工具是纯问题生成器——它不读代码、不浏览网页、不执行工具这些工作全部由主会话完成并将结果以“回答”的形式回喂给访谈。由此访谈对两件事异常敏感而其他阶段可以容忍回答保真度Answer fidelity。一条被截断或压缩的回答会成为模糊度评分ambiguity scoring的 ground truth也是驱动下一问的唯一信号。其他阶段execute、evaluate可以从产物artifacts重新推导上下文访谈做不到。适配器递归Adapter recursion。其他阶段运行数秒、只需少量 LLM 调用访谈则在同一个 Python 进程内连续进行多轮。任何单次调用开销——包括claude子进程加载项目.mcp.json并启动插件服务器——都会逐轮累积。3. Change 1 — 提升提示预算让结构化回答完整抵达 LLM3.1 问题InterviewEnginesrc/ouroboros/bigbang/interview.py原先将单条回答内容上限设为800 字符、总提示上限设为4,800 字符系统提示最低 1,200留给历史约 3,600。800 字符上限最初是为规避 Claude Agent SDK CLI 的“过大提示返回空响应”怪癖而引入但该值被统一应用在所有适配器上导致任何超过一句话的内容都无法完整发送给 MCP。下游效果类似下面这样的结构化回答——[from-user][refined] Decision: Stripe Billing. Reasoning: ... Constraints: ... Codebase context: ...——在state.rounds中被完整保存安全校验器允许最大 10 KB但在_build_conversation_history构造下一问提示时被静默截断为 800 字符 …。Constraints、Codebase context、Out-of-scope 等部分从未到达 LLM。下一问基于第一句话生成把辩证式提问dialectic短路成“标签确认循环”。3.2 决策提高两个上限常量旧值新值_MAX_TOTAL_PROMPT_CHARS4,80016,000_MAX_USER_RESPONSE_CHARS8004,000_trim_messages_to_budget继续强制总预算总上限仍是安全网。3.3 源码现状预算机制已进一步框架化从当前仓库源码看预算机制在 RFC 落地的 16,000/4,000 基础上又做了序列化开销建模见 src/ouroboros/bigbang/interview.pyAGENT_SDK_CLI_EMPIRICAL_EMPTY_RESPONSE_CHARS 16_000本地 Agent SDK CLI 路径在序列化提示超过该规模时可能返回空补全的实测失效天花板不是裸message.content预算CLI 适配器会附加章节头、角色前缀、分隔符与最终响应指令。AGENT_SDK_CLI_FIXED_FRAMING_CHARS 1_500固定序列化预留覆盖适配器章节头/工具/执行指令。AGENT_SDK_CLI_PER_MESSAGE_FRAMING_CHARS 128每条消息预留覆盖角色前缀与分隔符防止“多轮短轮次”绕过原始内容检查而跨过失效悬崖。AGENT_SDK_CLI_SAFE_PROMPT_CHARS 14_000安全提示预算保留约 2k 余量。因此当前_MAX_TOTAL_PROMPT_CHARS AGENT_SDK_CLI_SAFE_PROMPT_CHARS14,000见 interview.py_MAX_USER_RESPONSE_CHARS 4000interview.py。_trim_messages_to_budget按“先保留前缀消息、再从最新倒序保留”的方式裁剪历史interview.py五轮压力测试下可完整保留最近约 3.5 轮更早轮次按预算守卫裁剪。3.4 证据RFC 记录了一次真实 LLM 往返claude-sonnet-4-51,223 字符结构化回答经ClaudeCodeAdapter[1/4] start_interview OK [2/4] ask_next_question (Q1, 149 chars) OK [3/4] record_response full preserved: True [4/4] ask_next_question (Q2, 358 chars) OK, no empty response Q2 quoted: Stripe Billing, monthly/annual recurring plans signals matched: [stripe, billing]Q2 直接引用了回答中的推理章节——这些内容在旧上限下会越过 800 字符截断线。五轮递增回答压力测试表明最接近的约 3.5 轮完整保真更早轮次被既有预算守卫裁剪。3.5 风险与对策800 字符上限原本是防御 Agent SDK CLI 空响应 bug 的。RFC 作者在新上限下用claude-sonnet-4-5完成了单次调用与 5 轮序列测试未复现该 bug。若特定适配器可能是较老的gemini-cli回归下一步是**按适配器能力per-adapter capability**处理而非全局回滚——这正是 RFC 第 6 节 Out of scope 中预告的后续 RFC。4. Change 2 — Refine 与 Restate 关卡从“压成一行”到“保留一切”4.1 问题旧版skills/interview/SKILL.md的 Path A Step 3 把回答载荷演示为单行字符串answer: [from-code] JWT-based auth in src/auth/jwt.py or [from-user] Stripe Billing这种格式可读但把用户的推理、约束与范围决策折叠成一个标签。叠加 800 字符上限即使用户表达了丰富的上下文主会话也会在转发前将其压缩。底层技能集wonder/reflect/refine/restate的苏格拉底意图——尤其是refine规则中的“여기 빠진 결은 없습니까?”是否有遗漏的细节——完全没有编码进访谈流程。4.2 决策两道关卡 一套载荷 SchemaRFC 规定在 skills/interview/SKILL.md 中新增三处Step 3 — 多章节载荷默认化。仅 PATH 1a 自动确认事实与简短 PATH 2 回答yes/no/单个名词允许单行所有自由文本回答以多章节块发送Decision / Reasoning / Constraints / Out of scope / Codebase context。Step 4 — 转发前 Refine。自由文本回答先经过一次AskUserQuestion确认结构化载荷保留了每一项推理、约束与范围要素用户可接受、增补章节或重写。自动确认事实与选项确认跳过此关卡。Step 9 — Restate 关卡后置 Acceptance Guard。Seed-ready Acceptance Guard 通过后主会话将达成共识的目标复述为单句并请用户确认。这是整个访谈中唯一以单行压缩为目标的地方——其余回答全程保持多章节形式。Path B 的 agent 模式流程以引用方式继承两道关卡。当前 skills/interview/SKILL.md 中的 “Non-Skippable Gates” 与 Required Skill Capabilitiesrefine_answer、restate_goal正是这一落地的直接体现。4.3 为什么是“重释”Refine 而不是照搬独立refine技能会把候选含义折叠为一条共享含义行。照搬到访谈中会重新引入本 RFC 正在解决的压缩问题。refine的底层原则是“不漏掉任何细微差别”miss no nuance——该原则由 Step 4 以结构保留而非行合并的方式延续单行复述只在 Restate 关卡发生一次且那里压缩是明确目标。4.4 证据与 Change 1 相同的往返测试结构化载荷就位后Q2 引用回答的具体推理而非要求复述标题决策。访谈从“标签确认循环”变成“关于约束与权衡的辩证对话”。补充可运行细节当前 SKILL.md 还强化了 Restate 关卡与 Refine 的耦合——Restate 的 “Adjust wording” / “Missing scope” 跟进的任何自由文本修正都必须走 Refine 关卡即使只有一句话也必须以[from-user][refined]配合last_question重新打开 MCP 会话否则 MCP 会停留在修正前的陈旧状态上生成 Seed。这是阅读 skills/interview/SKILL.md 第 671-754 行时可验证的细节。5. Change 3 — 适配器 MCP 隔离斩断自递归5.1 问题用户标记为最关键的变更ClaudeCodeAdapter接受strict_mcp_config: bool参数其 docstring 明确写道Used exclusively by callers that must avoid recursion into the ouroboros MCP server (notably the interview policy path); genericallowed_toolsenvelopes keep MCP-tool access intact.嵌套 MCP 访谈处理句柄在构造问题生成适配器时必须设置该标志。若不显式开启处理句柄发出的 LLM 调用会生成一个claude子进程该子进程发现项目.mcp.json并在其内部启动 ouroboros-mcp。当访谈运行在 ouroboros 仓库自身时就产生自递归循环ouroboros-mcp → interview tool → claude 子进程 → ouroboros-mcp → ...启动成本逐轮累积。RFC 在同一 cwd 下测量同一 3 轮访谈Q1Q2Q3无隔离11.3 s38.4 s102.8 s有隔离22.0 s19.6 s32.6 s无隔离时 Q3 在较短超时下超过默认 120 秒超时表现为“访谈在第 3 轮挂起”且无有效错误信息。5.2 决策作用域仅限嵌套 MCP 入口嵌套 MCP 访谈处理句柄在调用 LLM 适配器工厂时请求strict_mcp_configTrue。隔离被限定在递归 MCP 入口InterviewEngine本身不包装或变更适配器因为 CLI 与 PM 访谈流程可能确实需要项目/插件.mcp.json条目保持可达。ClaudeCodeAdapter新增with_strict_mcp_config()工厂方法复制构造参数并返回新实例避免变异与非访谈阶段共享的适配器同时为显式调用者提供小型作用域选择辅助# src/ouroboros/mcp/tools/authoring_handlers.py — nested MCP handler adapter create_llm_adapter( ..., use_caseinterview, strict_mcp_configTrue, )# src/ouroboros/providers/claude_code_adapter.py — new method def with_strict_mcp_config(self) - ClaudeCodeAdapter: if self._strict_mcp_config: return self return ClaudeCodeAdapter(... strict_mcp_configTrue)5.3 源码现状与 RFC 设计逐点对应当前仓库实现与 RFC 设计完全吻合claude_code_adapter.py构造器strict_mcp_config: bool Falsedocstring 与 RFC 引用一致。claude_code_adapter.pywith_strict_mcp_config()已实现——已 strict 时返回self幂等否则用strict_mcp_configTrue复制构造参数克隆。factory.py工厂不从use_case自动推导strict_mcp_config原样转发注释明确说明非 MCP 访谈入口CLIooo init/ooo pm需要保留插件与项目.mcp.json服务器可达只有嵌套 MCP 工具入口InterviewHandler.handle显式选择开启。authoring_handlers.pyInterviewHandler._create_interview_engine以max_turns1、use_caseinterview、strict_mcp_configTrue调用create_llm_adapter且注释完整记录了对 #765 与 #1537 的关联allowed_tools[]必须搭配无工具提示变体防止模型发出幻影工具调用烧掉唯一轮次。pm_handler.pyPMInterviewHandler镜像了 #765 的 opt-in同样传strict_mcp_configTrue。codex_cli_adapter.pyCodex CLI 适配器同样支持该参数strict 模式下会检查是否存在有效的 ouroboros MCP 配置codex_cli_adapter.py。5.4 为什么显式 opt-in嵌套 MCP 访谈 LLM没有任何正当理由使用插件 MCP 服务器——按设计它不读代码、不浏览网页、不调用工具。在该边界显式隔离即可移除递归 footgun同时保留非嵌套 CLI 与 PM 行为。若未来某个用例需要在访谈期访问外部 MCP 服务器应建模为嵌套处理句柄/工厂路径上strict_mcp_config的兄弟新选项。5.5 证据单元测试RFC 记录 当前仓库可验证test_interview.pyInterviewEngine(llm_adapteradapter_with_helper)构造时engine.llm_adapter保持原适配器且with_strict_mcp_config()不被调用。test_interview_strict_mcp_config_wiring.pyInterviewHandler.handle()调用create_llm_adapter()时断言use_case interview且strict_mcp_config is True。test_claude_code_adapter.pywith_strict_mcp_config()返回严格克隆已是严格时返回self幂等。真实 LLMcwd 有意指向含.mcp.json的 ouroboros-gemini3[real] post-init adapter strictTrue [Q1] 22.0s (117 chars) [Q2] 19.6s (122 chars) [Q3] 32.6s (770 chars)无延迟累积、无超时。隔离去掉 MCP 开销后模型把预算花在问题质量而非子进程空转上——Q3 产出 770 字符的问题。6. Out of scope三件被有意推迟的事按适配器能力的上限Per-adapter cap capability。Change 1 保留单一全局上限若在特定适配器上回归后续 RFC 将把常量替换为按适配器的能力字段。Reflect-litePATH 1b/4 确认中的配对含义选项。最初草图包含“你的含义 vs. 我的含义”选项对为保持 SKILL 补丁面小而推迟Refine 关卡对自由文本回答已捕获同样意图。子代理路径上限subagent.py。OpenCode 子代理分发路径的 300/220/600 字符上限_INTERVIEW_SUBAGENT_MAX_ANSWER_CHARS、_INTERVIEW_SUBAGENT_MAX_TRANSCRIPT_ANSWER_CHARS、_INTERVIEW_SUBAGENT_MAX_CONTEXT_CHARS保持不变——它们是不同代码路径不用于主 MCP 模式访谈需要专门审计。7. 迁移 / 发布顺序三个 PR 均向后兼容PR 1只改常量值无 API 变更最坏情况是回退两个整数。PR 2仅对 skills/interview/SKILL.md 做文档级变更。PR 3给ClaudeCodeAdapter增加一个方法并在嵌套 MCP 处理句柄/工厂边界保留strict_mcp_configTrueopt-inCLI 与 PM 访谈流程不变。推荐的落地顺序RFC 明确论证PR 3适配器隔离最先——修复今天即存在的潜在递归 bug与另两项无关。PR 1上限提升其次——解锁辩证对话但单独落地无害。PR 2Refine/Restate 关卡最后——依赖 PR 1不提高上限多章节载荷仍会被截断并受益于 PR 3更快的轮次让额外一次 RefineAskUserQuestion显得廉价。8. Open Questions当前仍开放with_strict_mcp_config是否应提升到基类LLMAdapter协议并默认return self当前实现保留为ClaudeCodeAdapter的显式调用辅助目前足够。_MAX_TOTAL_PROMPT_CHARS是否应变成可用环境变量覆盖的配置让高级用户无需改代码即可调优若 Change 1 在各适配器上证明稳定答案很可能为“是”。9. 关联源码与测试索引主题路径RFC 原文docs/rfc/interview-hardening.md访谈引擎与预算常量src/ouroboros/bigbang/interview.py访谈技能Refine/Restate 关卡skills/interview/SKILL.mdClaude 适配器与with_strict_mcp_configsrc/ouroboros/providers/claude_code_adapter.py适配器工厂不自动推导 strict 标志src/ouroboros/providers/factory.py嵌套 MCP 访谈处理句柄src/ouroboros/mcp/tools/authoring_handlers.pyPM 访谈镜像 opt-insrc/ouroboros/mcp/tools/pm_handler.py子代理路径未变更上限src/ouroboros/mcp/tools/subagent.pystrict MCP 接线锁测试tests/unit/mcp/tools/test_interview_strict_mcp_config_wiring.py克隆与幂等测试tests/unit/providers/test_claude_code_adapter.py引擎不包装适配器测试tests/unit/bigbang/test_interview.py总结interview-hardening 的三项变更分别从“内容能否完整抵达 LLM”“回答以何种结构抵达 LLM”“生成问题的子进程是否会递归启动 MCP”三个层面守护访谈的苏格拉底质量。它们相互独立、可单独回退且每一层都有源码与测试锁定——理解这三道防线是深入 ouroboros 访谈管道、排查问题轮次或扩展新适配器时的必修课。赞分享AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载相关推荐marshmallow 升级指南从 1.x 迁移到 4.x 的完整兼容策略与代码迁移实战marshmallow 升级指南从 1.x 迁移到 4.x 的完整兼容策略与代码迁移实战 本文以 docs/upgrading.rst https://linAI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Chain-bench的Docker部署与容器化最佳实践Chain bench的Docker部署与容器化最佳实践 Chain bench是一款基于CIS软件供应链基准的开源安全合规审计工具专为软件供应链堆栈安全审计es-toolkit compat 的 intersectionWith 详解用自定义比较函数求多数组交集es toolkit compat 的 intersectionWith 详解用自定义比较函数求多数组交集 intersectionWith 是 es too后端虚拟化容器运行时上一篇MiGPT终极指南3步让你的小爱音箱变身AI语音助手下一篇3步让小爱音箱变身AI语音助手MiGPT完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ouroboros 访谈加固（Interview Hardening）：提示预算、Refine/Restate 关卡与适配器 MCP 隔离实战
AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载导读本文围绕 ouroboros 项目中已评审通过的 RFC interview-hardening.md 展开系统讲解其三项核心加固提升访谈Interview阶段单条回答与整体提示的字符预算、在 skills/interview/SKILL.md 中落地 Refine精炼确认与 Restate一句话复述两道关卡、以及在嵌套 MCP 访谈入口强制开启strict_mcp_config适配器隔离以防止 ouroboros MCP 服务自递归启动。读完本文你将掌握 ouroboros 访谈管道防止静默截断、防止单行答案压缩、防止自我递归的完整原理、配置参数演进与对应的源码与测试证据可直接用于排查“访谈第三轮挂起”“下一问总是停留在标签确认”等实际问题。1. RFC 定位一次观察驱动三项独立加固1.1 状态与落地方式该 RFC 状态为Accepted2026-05-11由三个相互独立、可分别合并的 PR 实施PR分支内容#822feat/interview-adapter-isolation适配器隔离嵌套 MCP 边界显式请求strict_mcp_configTrue#823feat/interview-prompt-cap-raise提示预算提升单条回答与总提示字符上限#824feat/interview-refine-restateRefine/Restate 关卡写入skills/interview/SKILL.md三个 PR 动机一致均源自一个底层观察访谈 LLM 是一个不带任何工具的问题生成器question generator主会话main session是通向它的唯一上下文通道。任何丢弃、压缩或递归重生成上下文的操作都会劣化访谈的苏格拉底式提问质量。1.2 范围说明Scope NoteRFC 中第 3 项变更在合并实现时有一个重要范围收敛strict_mcp_configTrue只应用于嵌套 MCP 处理句柄边界src/ouroboros/mcp/tools/authoring_handlers.py 中的InterviewHandler而非全局默认开启于InterviewEngine.__post_init__。CLI 与 PM 访谈入口ooo init/ooo pm保留原有的插件/项目.mcp.json行为对这些入口启用更严格默认策略需等待 MCP 宿主之外的自我生成self-spawn实证测量后另行跟进。这一范围说明在当前源码中依然成立下文第 4 节会给出代码级印证。2. 背景访谈是主会话的提问而不是 LLM 的提问RFC 明确指出commands/interview.md与 skills/interview/SKILL.md 已确立访谈 MCP 工具是纯问题生成器——它不读代码、不浏览网页、不执行工具这些工作全部由主会话完成并将结果以“回答”的形式回喂给访谈。由此访谈对两件事异常敏感而其他阶段可以容忍回答保真度Answer fidelity。一条被截断或压缩的回答会成为模糊度评分ambiguity scoring的 ground truth也是驱动下一问的唯一信号。其他阶段execute、evaluate可以从产物artifacts重新推导上下文访谈做不到。适配器递归Adapter recursion。其他阶段运行数秒、只需少量 LLM 调用访谈则在同一个 Python 进程内连续进行多轮。任何单次调用开销——包括claude子进程加载项目.mcp.json并启动插件服务器——都会逐轮累积。3. Change 1 — 提升提示预算让结构化回答完整抵达 LLM3.1 问题InterviewEnginesrc/ouroboros/bigbang/interview.py原先将单条回答内容上限设为800 字符、总提示上限设为4,800 字符系统提示最低 1,200留给历史约 3,600。800 字符上限最初是为规避 Claude Agent SDK CLI 的“过大提示返回空响应”怪癖而引入但该值被统一应用在所有适配器上导致任何超过一句话的内容都无法完整发送给 MCP。下游效果类似下面这样的结构化回答——[from-user][refined] Decision: Stripe Billing. Reasoning: ... Constraints: ... Codebase context: ...——在state.rounds中被完整保存安全校验器允许最大 10 KB但在_build_conversation_history构造下一问提示时被静默截断为 800 字符 …。Constraints、Codebase context、Out-of-scope 等部分从未到达 LLM。下一问基于第一句话生成把辩证式提问dialectic短路成“标签确认循环”。3.2 决策提高两个上限常量旧值新值_MAX_TOTAL_PROMPT_CHARS4,80016,000_MAX_USER_RESPONSE_CHARS8004,000_trim_messages_to_budget继续强制总预算总上限仍是安全网。3.3 源码现状预算机制已进一步框架化从当前仓库源码看预算机制在 RFC 落地的 16,000/4,000 基础上又做了序列化开销建模见 src/ouroboros/bigbang/interview.pyAGENT_SDK_CLI_EMPIRICAL_EMPTY_RESPONSE_CHARS 16_000本地 Agent SDK CLI 路径在序列化提示超过该规模时可能返回空补全的实测失效天花板不是裸message.content预算CLI 适配器会附加章节头、角色前缀、分隔符与最终响应指令。AGENT_SDK_CLI_FIXED_FRAMING_CHARS 1_500固定序列化预留覆盖适配器章节头/工具/执行指令。AGENT_SDK_CLI_PER_MESSAGE_FRAMING_CHARS 128每条消息预留覆盖角色前缀与分隔符防止“多轮短轮次”绕过原始内容检查而跨过失效悬崖。AGENT_SDK_CLI_SAFE_PROMPT_CHARS 14_000安全提示预算保留约 2k 余量。因此当前_MAX_TOTAL_PROMPT_CHARS AGENT_SDK_CLI_SAFE_PROMPT_CHARS14,000见 interview.py_MAX_USER_RESPONSE_CHARS 4000interview.py。_trim_messages_to_budget按“先保留前缀消息、再从最新倒序保留”的方式裁剪历史interview.py五轮压力测试下可完整保留最近约 3.5 轮更早轮次按预算守卫裁剪。3.4 证据RFC 记录了一次真实 LLM 往返claude-sonnet-4-51,223 字符结构化回答经ClaudeCodeAdapter[1/4] start_interview OK [2/4] ask_next_question (Q1, 149 chars) OK [3/4] record_response full preserved: True [4/4] ask_next_question (Q2, 358 chars) OK, no empty response Q2 quoted: Stripe Billing, monthly/annual recurring plans signals matched: [stripe, billing]Q2 直接引用了回答中的推理章节——这些内容在旧上限下会越过 800 字符截断线。五轮递增回答压力测试表明最接近的约 3.5 轮完整保真更早轮次被既有预算守卫裁剪。3.5 风险与对策800 字符上限原本是防御 Agent SDK CLI 空响应 bug 的。RFC 作者在新上限下用claude-sonnet-4-5完成了单次调用与 5 轮序列测试未复现该 bug。若特定适配器可能是较老的gemini-cli回归下一步是**按适配器能力per-adapter capability**处理而非全局回滚——这正是 RFC 第 6 节 Out of scope 中预告的后续 RFC。4. Change 2 — Refine 与 Restate 关卡从“压成一行”到“保留一切”4.1 问题旧版skills/interview/SKILL.md的 Path A Step 3 把回答载荷演示为单行字符串answer: [from-code] JWT-based auth in src/auth/jwt.py or [from-user] Stripe Billing这种格式可读但把用户的推理、约束与范围决策折叠成一个标签。叠加 800 字符上限即使用户表达了丰富的上下文主会话也会在转发前将其压缩。底层技能集wonder/reflect/refine/restate的苏格拉底意图——尤其是refine规则中的“여기 빠진 결은 없습니까?”是否有遗漏的细节——完全没有编码进访谈流程。4.2 决策两道关卡 一套载荷 SchemaRFC 规定在 skills/interview/SKILL.md 中新增三处Step 3 — 多章节载荷默认化。仅 PATH 1a 自动确认事实与简短 PATH 2 回答yes/no/单个名词允许单行所有自由文本回答以多章节块发送Decision / Reasoning / Constraints / Out of scope / Codebase context。Step 4 — 转发前 Refine。自由文本回答先经过一次AskUserQuestion确认结构化载荷保留了每一项推理、约束与范围要素用户可接受、增补章节或重写。自动确认事实与选项确认跳过此关卡。Step 9 — Restate 关卡后置 Acceptance Guard。Seed-ready Acceptance Guard 通过后主会话将达成共识的目标复述为单句并请用户确认。这是整个访谈中唯一以单行压缩为目标的地方——其余回答全程保持多章节形式。Path B 的 agent 模式流程以引用方式继承两道关卡。当前 skills/interview/SKILL.md 中的 “Non-Skippable Gates” 与 Required Skill Capabilitiesrefine_answer、restate_goal正是这一落地的直接体现。4.3 为什么是“重释”Refine 而不是照搬独立refine技能会把候选含义折叠为一条共享含义行。照搬到访谈中会重新引入本 RFC 正在解决的压缩问题。refine的底层原则是“不漏掉任何细微差别”miss no nuance——该原则由 Step 4 以结构保留而非行合并的方式延续单行复述只在 Restate 关卡发生一次且那里压缩是明确目标。4.4 证据与 Change 1 相同的往返测试结构化载荷就位后Q2 引用回答的具体推理而非要求复述标题决策。访谈从“标签确认循环”变成“关于约束与权衡的辩证对话”。补充可运行细节当前 SKILL.md 还强化了 Restate 关卡与 Refine 的耦合——Restate 的 “Adjust wording” / “Missing scope” 跟进的任何自由文本修正都必须走 Refine 关卡即使只有一句话也必须以[from-user][refined]配合last_question重新打开 MCP 会话否则 MCP 会停留在修正前的陈旧状态上生成 Seed。这是阅读 skills/interview/SKILL.md 第 671-754 行时可验证的细节。5. Change 3 — 适配器 MCP 隔离斩断自递归5.1 问题用户标记为最关键的变更ClaudeCodeAdapter接受strict_mcp_config: bool参数其 docstring 明确写道Used exclusively by callers that must avoid recursion into the ouroboros MCP server (notably the interview policy path); genericallowed_toolsenvelopes keep MCP-tool access intact.嵌套 MCP 访谈处理句柄在构造问题生成适配器时必须设置该标志。若不显式开启处理句柄发出的 LLM 调用会生成一个claude子进程该子进程发现项目.mcp.json并在其内部启动 ouroboros-mcp。当访谈运行在 ouroboros 仓库自身时就产生自递归循环ouroboros-mcp → interview tool → claude 子进程 → ouroboros-mcp → ...启动成本逐轮累积。RFC 在同一 cwd 下测量同一 3 轮访谈Q1Q2Q3无隔离11.3 s38.4 s102.8 s有隔离22.0 s19.6 s32.6 s无隔离时 Q3 在较短超时下超过默认 120 秒超时表现为“访谈在第 3 轮挂起”且无有效错误信息。5.2 决策作用域仅限嵌套 MCP 入口嵌套 MCP 访谈处理句柄在调用 LLM 适配器工厂时请求strict_mcp_configTrue。隔离被限定在递归 MCP 入口InterviewEngine本身不包装或变更适配器因为 CLI 与 PM 访谈流程可能确实需要项目/插件.mcp.json条目保持可达。ClaudeCodeAdapter新增with_strict_mcp_config()工厂方法复制构造参数并返回新实例避免变异与非访谈阶段共享的适配器同时为显式调用者提供小型作用域选择辅助# src/ouroboros/mcp/tools/authoring_handlers.py — nested MCP handler adapter create_llm_adapter( ..., use_caseinterview, strict_mcp_configTrue, )# src/ouroboros/providers/claude_code_adapter.py — new method def with_strict_mcp_config(self) - ClaudeCodeAdapter: if self._strict_mcp_config: return self return ClaudeCodeAdapter(... strict_mcp_configTrue)5.3 源码现状与 RFC 设计逐点对应当前仓库实现与 RFC 设计完全吻合claude_code_adapter.py构造器strict_mcp_config: bool Falsedocstring 与 RFC 引用一致。claude_code_adapter.pywith_strict_mcp_config()已实现——已 strict 时返回self幂等否则用strict_mcp_configTrue复制构造参数克隆。factory.py工厂不从use_case自动推导strict_mcp_config原样转发注释明确说明非 MCP 访谈入口CLIooo init/ooo pm需要保留插件与项目.mcp.json服务器可达只有嵌套 MCP 工具入口InterviewHandler.handle显式选择开启。authoring_handlers.pyInterviewHandler._create_interview_engine以max_turns1、use_caseinterview、strict_mcp_configTrue调用create_llm_adapter且注释完整记录了对 #765 与 #1537 的关联allowed_tools[]必须搭配无工具提示变体防止模型发出幻影工具调用烧掉唯一轮次。pm_handler.pyPMInterviewHandler镜像了 #765 的 opt-in同样传strict_mcp_configTrue。codex_cli_adapter.pyCodex CLI 适配器同样支持该参数strict 模式下会检查是否存在有效的 ouroboros MCP 配置codex_cli_adapter.py。5.4 为什么显式 opt-in嵌套 MCP 访谈 LLM没有任何正当理由使用插件 MCP 服务器——按设计它不读代码、不浏览网页、不调用工具。在该边界显式隔离即可移除递归 footgun同时保留非嵌套 CLI 与 PM 行为。若未来某个用例需要在访谈期访问外部 MCP 服务器应建模为嵌套处理句柄/工厂路径上strict_mcp_config的兄弟新选项。5.5 证据单元测试RFC 记录 当前仓库可验证test_interview.pyInterviewEngine(llm_adapteradapter_with_helper)构造时engine.llm_adapter保持原适配器且with_strict_mcp_config()不被调用。test_interview_strict_mcp_config_wiring.pyInterviewHandler.handle()调用create_llm_adapter()时断言use_case interview且strict_mcp_config is True。test_claude_code_adapter.pywith_strict_mcp_config()返回严格克隆已是严格时返回self幂等。真实 LLMcwd 有意指向含.mcp.json的 ouroboros-gemini3[real] post-init adapter strictTrue [Q1] 22.0s (117 chars) [Q2] 19.6s (122 chars) [Q3] 32.6s (770 chars)无延迟累积、无超时。隔离去掉 MCP 开销后模型把预算花在问题质量而非子进程空转上——Q3 产出 770 字符的问题。6. Out of scope三件被有意推迟的事按适配器能力的上限Per-adapter cap capability。Change 1 保留单一全局上限若在特定适配器上回归后续 RFC 将把常量替换为按适配器的能力字段。Reflect-litePATH 1b/4 确认中的配对含义选项。最初草图包含“你的含义 vs. 我的含义”选项对为保持 SKILL 补丁面小而推迟Refine 关卡对自由文本回答已捕获同样意图。子代理路径上限subagent.py。OpenCode 子代理分发路径的 300/220/600 字符上限_INTERVIEW_SUBAGENT_MAX_ANSWER_CHARS、_INTERVIEW_SUBAGENT_MAX_TRANSCRIPT_ANSWER_CHARS、_INTERVIEW_SUBAGENT_MAX_CONTEXT_CHARS保持不变——它们是不同代码路径不用于主 MCP 模式访谈需要专门审计。7. 迁移 / 发布顺序三个 PR 均向后兼容PR 1只改常量值无 API 变更最坏情况是回退两个整数。PR 2仅对 skills/interview/SKILL.md 做文档级变更。PR 3给ClaudeCodeAdapter增加一个方法并在嵌套 MCP 处理句柄/工厂边界保留strict_mcp_configTrueopt-inCLI 与 PM 访谈流程不变。推荐的落地顺序RFC 明确论证PR 3适配器隔离最先——修复今天即存在的潜在递归 bug与另两项无关。PR 1上限提升其次——解锁辩证对话但单独落地无害。PR 2Refine/Restate 关卡最后——依赖 PR 1不提高上限多章节载荷仍会被截断并受益于 PR 3更快的轮次让额外一次 RefineAskUserQuestion显得廉价。8. Open Questions当前仍开放with_strict_mcp_config是否应提升到基类LLMAdapter协议并默认return self当前实现保留为ClaudeCodeAdapter的显式调用辅助目前足够。_MAX_TOTAL_PROMPT_CHARS是否应变成可用环境变量覆盖的配置让高级用户无需改代码即可调优若 Change 1 在各适配器上证明稳定答案很可能为“是”。9. 关联源码与测试索引主题路径RFC 原文docs/rfc/interview-hardening.md访谈引擎与预算常量src/ouroboros/bigbang/interview.py访谈技能Refine/Restate 关卡skills/interview/SKILL.mdClaude 适配器与with_strict_mcp_configsrc/ouroboros/providers/claude_code_adapter.py适配器工厂不自动推导 strict 标志src/ouroboros/providers/factory.py嵌套 MCP 访谈处理句柄src/ouroboros/mcp/tools/authoring_handlers.pyPM 访谈镜像 opt-insrc/ouroboros/mcp/tools/pm_handler.py子代理路径未变更上限src/ouroboros/mcp/tools/subagent.pystrict MCP 接线锁测试tests/unit/mcp/tools/test_interview_strict_mcp_config_wiring.py克隆与幂等测试tests/unit/providers/test_claude_code_adapter.py引擎不包装适配器测试tests/unit/bigbang/test_interview.py总结interview-hardening 的三项变更分别从“内容能否完整抵达 LLM”“回答以何种结构抵达 LLM”“生成问题的子进程是否会递归启动 MCP”三个层面守护访谈的苏格拉底质量。它们相互独立、可单独回退且每一层都有源码与测试锁定——理解这三道防线是深入 ouroboros 访谈管道、排查问题轮次或扩展新适配器时的必修课。赞分享AI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具【免费下载链接】ouroborosAgent OS: the agent gets smarter on its own. We just hold the line: Interview-gated, staged evaluation, budgeted evolution loop. MCP server, 14 runtimes: Claude Code, Codex CLI, Gemini CLI, OpenCode, Copilot, Kiro and more.项目地址https://gitcode.com/gh_mirrors/ouroboros13/ouroboros点击查看免费下载相关推荐marshmallow 升级指南从 1.x 迁移到 4.x 的完整兼容策略与代码迁移实战marshmallow 升级指南从 1.x 迁移到 4.x 的完整兼容策略与代码迁移实战 本文以 docs/upgrading.rst https://linAI Agent人工智能代码智能体Agent 编排AI 评测CLI开发工具Chain-bench的Docker部署与容器化最佳实践Chain bench的Docker部署与容器化最佳实践 Chain bench是一款基于CIS软件供应链基准的开源安全合规审计工具专为软件供应链堆栈安全审计es-toolkit compat 的 intersectionWith 详解用自定义比较函数求多数组交集es toolkit compat 的 intersectionWith 详解用自定义比较函数求多数组交集 intersectionWith 是 es too后端虚拟化容器运行时上一篇MiGPT终极指南3步让你的小爱音箱变身AI语音助手下一篇3步让小爱音箱变身AI语音助手MiGPT完整指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考