https://codexer.com/tags/%E7%BB%93%E6%9E%84%E5%8C%96%E8%88%B5%E8%BD%AE/Recent content in 结构化舵轮 on CodexerHugozh-cnSat, 15 Aug 2026 09:00:00 +0800https://codexer.com/posts/2026-08-15-codex-structured-steering-assumptions/Sat, 15 Aug 2026 09:00:00 +0800https://codexer.com/posts/2026-08-15-codex-structured-steering-assumptions/<p>你让 Codex 接手一个 API 迁移任务，自己转身去开会。半小时后回来，它已经改完了十几个文件，测试也写好了。你扫了一眼 diff，眉头皱了起来：它只改了核心路径，没有给旧调用方留兼容适配层。你问它为什么，它答得理直气壮：我以为你要直接 breaking change。</p> <p>这一刻你才意识到，真正拖慢进度的不是模型不够聪明，而是它替你做了太多默认决定。</p> <h2 id="隐性假设智能体编程里最贵的成本">隐性假设，智能体编程里最贵的成本</h2> <p>用智能体写代码，本质是一场协作，而协作的成本大多花在「对齐」上。对齐失败最常见的形态，不是模型写错代码，而是它在无数个小节点上替你做了默认决定：写多少测试？单元测试还是端到端？API 变了要不要留适配层？跑哪几条命令？要不要顺手重构旁边的文件？</p> <p>大多数时候它猜对了，于是你放任它一路狂奔。可一旦猜错，代价就来了。</p> <h2 id="为什么打断式纠错行不通">为什么「打断式纠错」行不通</h2> <p>发现问题之后，人的第一反应是打断它，说一句「别这样，要那样」。但打断有三个隐性代价。</p> <p>第一，污染上下文。每一次纠正都是一段来回对话，这些澄清消息挤占了本该属于业务逻辑的注意力预算。模型要分出一部分精力去理解「你这次又改主意了」，而不是专注在代码本身。</p> <p>第二，来回反复会制造歧义。最典型的情况是「只跑这几个测试」变成「算了跑全套」又变回「还是只跑这几个」。当你的指令在三次以上反复横跳时，模型对「你究竟想要什么」的判断会变得模糊，后续决策质量跟着下滑。</p> <p>第三，打断是滞后的。等你发现问题时，它已经顺着错误假设跑出去很远，返工的成本早已沉没。</p> <h2 id="核心洞察假设不是对话是配置">核心洞察：假设不是对话，是配置</h2> <p>这些隐性假设有一个共同点：它们本该是配置，却一直被当成对话在处理。</p> <p>配置和对话的区别在于，配置是显式的、可预期的、可以在出错时一眼定位的状态；对话是流动的、易失的、淹没在历史消息里的文本。把一个本该是配置的东西放进对话，就等于把「决策状态」藏进了「聊天记录」，想回头改都找不到锚点。</p> <p>于是自然的思路浮出水面：能不能把这些隐形决策，实时地捞出来，摆到台面上？</p> <h2 id="一个观察者子代理如何工作">一个「观察者子代理」如何工作</h2> <p>最近有开发者给出了一个具体答案，叫结构化舵轮（Structured Steering）。它的做法很巧妙：不动主代理，而是另起一个更便宜的子代理，专门负责「盯梢」。</p> <p>这个观察者子代理没有工具、不能改文件、不能批准任何操作，它只做一件事，每次会话状态变化后，扫描最近的对话，找出主代理正在做的隐性假设，然后把它们翻译成一个个控件：开关、下拉框、选项列表。比如主代理决定「只测改动的行为」，观察者就生成一个「测试范围」下拉框，选项是「只测改动行为」和「覆盖所有迁移路径」。</p> <p>这些控件通过四个 Codex 钩子注入到主代理的上下文里：会话开始、用户提交新指令、工具调用前、工具调用后。关键在于，它注入的是额外的上下文片段（additionalContext），而不是写进对话历史，所以不会污染会话记录。控件只在值发生变化时才重新发送，未变化的控件不会让提示缓存失效。</p> <h2 id="冲突时听谁的">冲突时听谁的</h2> <p>一旦决策有了显式状态，就必然遇到冲突：同一个选项，观察者推断了一个值，你在弹窗里点了另一个，模型又在聊天里听你说了第三个。这套机制给了一个清晰的优先级：你新发的明确指令，永远压过更早的界面点击；界面点击压过观察者早先的推断；而安全策略则凌驾于一切之上。</p> <p>为了让并发更新不出乱子，每个会话的状态用一个带版本号的 state.json 保存，另附一份带时间戳的事件日志。一次更新会带上它基于的版本号，如果期间已经被更新，旧改动就会被丢弃，避免把过期的推断覆盖到新状态上。</p> <h2 id="我的判断从提示词工程到舵轮工程">我的判断：从「提示词工程」到「舵轮工程」</h2> <p>这个思路真正打动我的地方，不在于那个弹窗本身，而在于它暗示了一个方向上的转变。</p> <p>过去一年我们谈的都是提示词工程，想靠更精心的措辞去约束模型行为。但提示词是软的，模型的默认行为藏在权重里，光靠文字很难摁住。结构化舵轮换了个思路：把「你希望它怎么做」从对话里抽出来，变成一套可读、可写、可持久化的状态，让人类在任何一个时间点都能看到模型此刻正在替自己做哪些决定，并且随手拨正。</p> <p>这和 Codex 已经有的 Goals 机制一脉相承，只不过 Goals 是你在开始前主动写下的目标，而舵轮是模型在运行中不断产生的、连你自己都可能没意识到的那些默认选择。</p> <p>我更愿意把它看成智能体形态演进的一个信号：当编程智能体越来越自主，人类和它之间的接口会从「一问一答」逐渐让位给「一套持续对齐的控制面板」。到那时，评测一个智能体的好坏，可能不再只看它一次能写对多少代码，还要看它能不能把自己的决策透明地摊开，让你一眼看穿它在替你做哪些主。</p> <p>参考来源：https://github.com/pirate/codex-structured-steering （Structured Steering，一个兼容 Codex 桌面端与 CLI 的开源实验项目，本文据此提炼核心思路并加入独立分析）</p>