1. 为什么要在 Coding Agent 外面再套一层决策层1.1 从两个真实痛点说起先说一个我踩过的坑。去年有一段时间我同时用两个 Coding Agent 处理日常开发任务一个负责偏工程化的重构和脚本生成另一个负责偏探索性的代码理解和方案推演。用着用着就发现一个很尴尬的问题——每次遇到一个任务我得先自己判断这个活该丢给谁。判断本身不费劲但判断的过程会打断心流而且我经常判断错明明是个需要长上下文推理的活我丢给了擅长快速改文件的那个结果来回改了三轮才收敛。第二个坑更隐蔽。Coding Agent 本身是有决策能力的但它的决策是任务内决策——给定一个 prompt它决定先读哪个文件、先改哪一行、要不要跑测试。它缺的是任务前决策——这个任务到底该不该现在做、该用哪种模式做、该带多少上下文进去。这两层决策混在一起导致 Agent 经常在错误的层面上使劲。Jev 接入 Claude Code 与 Codex这件事本质上就是解决这两个坑在 Coding Agent 之上加一层快速决策能力让选谁做、怎么做、带什么进去这三件事在进入 Agent 之前就被快速定下来。Jev 在这里扮演的是决策层的角色Claude Code 和 Codex 是被调度的执行层。1.2 这层决策能力到底解决什么问题我把这层能力要解决的问题拆成三类你可以对照自己的场景看看中了几条路由问题同一个需求不同 Agent 的擅长区间不一样。有的擅长在已有代码库里做精准修改有的擅长从零生成一段独立逻辑有的擅长读大量文件后给出结论。人工路由慢且不稳定。上下文问题Agent 的表现极度依赖喂进去的上下文。喂多了它抓不住重点喂少了它瞎猜。快速决策层要能在进入 Agent 前把上下文裁剪到刚好够用。收敛问题一个任务要不要拆成多轮、每轮的验收标准是什么、什么时候该停下来问人。这些如果全交给 Agent 自己判断很容易陷入改—测—再改的循环。注意这层决策能力不是要替代 Agent 的推理而是把元决策从 Agent 内部抽出来放到一个更快、更可控、更便宜的地方。这是整个方案的核心设计哲学后面所有细节都围绕它展开。1.3 适合谁来参考这套思路如果你符合下面任意一条这篇内容对你会比较有用日常已经在用至少一个 Coding Agent但觉得每次都要自己想怎么用很累团队里多人共用 Agent希望有一套统一的调度规则而不是各凭手感想给 Agent 加一层轻量的前置处理但不想引入重型编排框架对决策层这个概念感兴趣想看看在 Coding 场景里具体怎么落地。如果你只是偶尔用 Agent 写个一次性脚本那这套东西可能有点重可以先收藏等任务复杂度上来了再回来看。2. 整体架构设计决策层与执行层怎么分工2.1 三层结构输入归一化、快速决策、执行分发我把整个链路拆成三层从上到下依次是输入归一化层把用户五花八门的输入一句话需求、一段报错、一个文件路径、一段伪代码统一成结构化任务描述。快速决策层Jev 所在层基于结构化任务描述输出一个决策结果包含目标 Agent、上下文清单、执行模式、验收标准。执行分发层把决策结果翻译成对应 Agent 能接受的调用形式分别对接 Claude Code 和 Codex。这个分层的意义在于每一层都可以独立替换。比如你以后想接入第三个 Agent只需要在执行分发层加一个适配器决策层的逻辑完全不用动。反过来你想换一套决策规则执行层也感知不到。2.2 为什么决策层要快标题里快速决策这四个字不是修辞是硬约束。原因有三个决策层在关键路径上它挡在用户和 Agent 之间它慢一秒整个交互就慢一秒。Agent 本身执行可能要几十秒但决策层如果也要几秒用户体感就是卡。决策层要便宜如果决策层本身也调用一个大模型做推理那成本就翻倍了。快速决策层应该尽量用规则、轻量分类、缓存命中来完成大部分判断。决策层要可解释Agent 内部怎么想的你很难干预但决策层必须能说清楚为什么选了这个 Agent。否则出了问题你没法调。基于这三点我在设计时定了一个原则能用规则解决的绝不上模型能用缓存命中的绝不重新计算只有真正模糊的情况才走轻量推理。这个原则后面会反复出现。2.3 决策结果的数据结构决策层的输出我定义成一个固定结构这样执行层才好对接。字段大致如下字段含义示例target目标执行器claude-code / codexmode执行模式patch / generate / explorecontext上下文清单文件路径列表、片段范围acceptance验收标准测试通过、编译通过、人工确认max_rounds最大轮次3fallback兜底策略换 Agent 重试 / 直接问人这个结构看起来简单但每个字段背后都有一堆取舍。比如mode为什么只有三种而不是更细因为模式太细会导致决策层判断负担变重三种是够用且好判断的平衡点。max_rounds为什么要有因为不加这个Agent 很容易无限循环。2.4 与直接调用 Agent 的对比为了说清楚这层决策的价值我做个对比维度直接调用 Agent加决策层路由人工判断自动判断上下文人工挑选自动裁剪成本单次调用决策开销 单次调用可解释性弱强决策可记录扩展性换 Agent 要改习惯加适配器即可可以看到加决策层唯一的代价是决策开销而这个开销通过规则化和缓存可以压到很低。收益是可解释性和扩展性这两点在长期使用中价值很大。3. 核心细节解析决策层到底怎么判断3.1 任务分类先分清改和造决策层第一步是把任务分成两大类改已有代码和造新代码。这个判断看似简单但它是后续所有决策的基础。我的判断规则是这样的如果输入里包含明确的文件路径、函数名、报错信息且这些指向的是已有代码库里的东西归为改。如果输入是帮我写一个 XXX、实现一个 XXX 功能且没有指向具体文件归为造。如果两者都有比如在 XXX 文件里加一个 YYY 功能归为改因为主体是在已有结构里动刀。为什么这个分类重要因为改和造对 Agent 的要求完全不同。改要求 Agent 能精准理解现有代码的约束造要求 Agent 能快速产出可运行的结构。Claude Code 和 Codex 在这两件事上的表现差异是路由决策的主要依据。3.2 上下文裁剪给多少才刚好上下文裁剪是决策层里最容易被低估的一环。我见过太多人直接把整个仓库丢给 Agent然后抱怨 Agent 抓不住重点。实际上Agent 的注意力是有限的喂太多等于没喂。我的裁剪策略分三步锚点定位从输入里提取锚点比如报错的文件名、函数名、行号。锚点是裁剪的起点。扩散范围从锚点向外扩散扩散范围取决于任务类型。改任务扩散到调用方和被调用方造任务扩散到同类实现作为参考。预算控制给上下文设一个 token 预算超了就按相关性排序截断。这里有个经验值可以参考对于改任务上下文控制在 2000 到 8000 token 之间通常比较合适对于造任务参考实现的上下文控制在 3000 token 以内剩下的留给生成。这个数字不是绝对的但可以作为起点。提示裁剪的时候宁可少给一点让 Agent 主动去读也不要一次给太多。Agent 主动读文件的过程本身就是在建立理解这个理解比被动接收上下文更扎实。3.3 模式选择patch、generate、explore 的适用边界三种模式的边界我总结如下patch 模式适用于明确的局部修改。特征是改动范围可预期、验收标准明确比如测试通过。这种模式要求 Agent 输出 diff 而不是完整文件减少出错面。generate 模式适用于从零生成或大范围重写。特征是现有代码参考价值低、需要 Agent 自由发挥。这种模式允许 Agent 输出完整文件。explore 模式适用于我还不确定要改什么的情况。特征是任务描述模糊、需要先理解再动手。这种模式让 Agent 先输出分析报告人确认后再进入 patch 或 generate。模式选错的代价很大。我试过把本该 explore 的任务当成 patch 丢进去结果 Agent 在没理解全局的情况下改了一堆文件最后全回滚了。所以决策层在模式判断上要保守一点拿不准的时候先 explore。3.4 验收标准怎么定义做完了验收标准是决策层里最容易被忽略但最重要的一环。没有验收标准Agent 就不知道什么时候该停人也不知道该不该接受结果。我的验收标准分四级级别标准适用场景L1编译/语法通过任何代码改动的最低要求L2相关测试通过有测试覆盖的模块L3新增测试通过新增功能L4人工确认涉及设计决策的改动决策层要根据任务类型自动选一个级别。比如纯格式化改动 L1 就够新增功能至少要 L3。这个级别会写进决策结果执行层据此判断是否继续。4. 实操过程从零搭起这套决策链路4.1 环境准备与依赖梳理先说环境。这套东西对运行环境要求不高核心依赖就几样一个能跑脚本的运行时我用的是 Python你也可以用 Node两个 Agent 的调用入口Claude Code 和 Codex 各自的命令行或 API一个轻量的规则引擎其实用配置文件加 if-else 就够不用上重型框架一个缓存层本地文件缓存即可不用上 Redis。我特意把依赖压到最低因为决策层本身应该是透明的依赖越多越容易出问题。你如果只是想验证思路甚至可以先不接真实 Agent用 mock 把决策链路跑通再说。4.2 输入归一化的实现输入归一化这一步我写了一个简单的解析器把输入映射成结构化任务。核心逻辑如下def normalize(raw_input): task { raw: raw_input, anchors: extract_anchors(raw_input), # 文件路径、函数名、报错 intent: classify_intent(raw_input), # fix / create / explore scope: estimate_scope(raw_input), # local / module / repo } return taskextract_anchors用正则匹配文件路径和常见报错格式classify_intent用关键词加简单规则estimate_scope根据锚点数量和是否提到全局重构这类词来判断。这里有个细节不要在这一步做太重的 NLP。归一化的目标是够用不是完美。我一开始想用模型做意图分类后来发现规则能覆盖 80% 的情况剩下 20% 走兜底就行没必要为了 20% 把整条链路拖慢。4.3 决策规则的编写与优先级决策规则我用一个有序列表来组织从上到下匹配命中即停。大致长这样如果 intent 是 explore直接选 explore 模式目标 Agent 选擅长长上下文理解的那个。如果 intent 是 fix 且 scope 是 local选 patch 模式目标 Agent 选擅长精准修改的那个。如果 intent 是 create 且 scope 是 module选 generate 模式。如果 scope 是 repo无论 intent 是什么先降级为 explore因为大范围改动风险太高。兜底选 explore 模式让 Agent 先给分析。这个顺序很重要。风险高的规则要排在前面比如第 4 条大范围改动降级必须早于具体的 fix/create 判断否则会被后面的规则覆盖掉。4.4 对接 Claude Code 与 Codex 的适配层适配层的职责是把决策结果翻译成各 Agent 能接受的调用。两个 Agent 的接口形态不一样所以适配层要分别处理。对接 Claude Code 时我主要用它处理 patch 和 explore 模式因为它在理解现有代码结构上比较稳。调用时把 context 清单转成它认识的路径参数把 acceptance 转成它执行后要跑的验证命令。对接 Codex 时我主要用它处理 generate 模式因为它在从零产出结构上比较快。调用时把 context 作为参考片段传入把 max_rounds 作为它的重试上限。适配层的关键是把决策结果里的抽象字段翻译成具体参数。这一步不要偷懒翻译逻辑要写清楚否则出了问题你根本不知道是决策错了还是翻译错了。4.5 缓存与命中策略缓存是让决策层快起来的关键。我缓存两类东西任务指纹到决策结果的映射把归一化后的任务算一个指纹命中就直接返回上次的决策。锚点到上下文的映射同一个文件同一个函数裁剪出来的上下文基本一样可以复用。缓存失效策略我用的是文件修改时间 任务指纹双条件。文件没改、任务一样缓存就有效。实测下来重复任务的决策耗时能从几百毫秒降到几毫秒。注意缓存不要缓存决策过程只缓存决策结果。过程缓存会导致你调试时看到的是旧逻辑很容易误判。5. 常见问题与排查技巧实录5.1 决策层选错 Agent 怎么办这是最常见的问题。表现是任务丢给了 AA 做了一半卡住换 B 才做完。排查思路是回看决策记录看是哪条规则命中了、为什么命中。我遇到过的典型原因是锚点提取失败。比如输入里写的是那个处理用户登录的地方没有具体文件名锚点提取为空决策层只能走兜底规则。解决办法是在归一化层加一个模糊锚点处理如果提取不到精确锚点就用关键词去代码库里搜搜到候选再让用户确认。5.2 上下文给多了导致 Agent 跑偏表现是Agent 读了一堆无关文件然后在一个不相关的地方改了东西。排查时看决策结果里的 context 清单如果清单长度明显超过预算就是裁剪没生效。原因通常是扩散范围设太大。我的经验是扩散范围默认只扩一跳也就是只包含直接调用方和被调用方不要递归扩散。需要更多上下文时让 Agent 自己主动去读而不是一次性喂给它。5.3 验收标准太松导致反复返工表现是Agent 说做完了你一测发现没做完。排查时看决策结果里的 acceptance 级别如果任务明显需要 L3 但决策给了 L1就是级别判断错了。修正方法是在决策规则里加一条只要任务涉及新增逻辑acceptance 至少 L3。这条规则能挡掉大部分假完成。5.4 常见问题速查表现象可能原因排查动作解决方向选错 Agent锚点提取失败看决策记录加模糊锚点处理Agent 跑偏上下文超预算看 context 清单缩小扩散范围反复返工验收标准太松看 acceptance 级别提高级别下限决策变慢缓存未命中看缓存命中率优化指纹算法无限循环max_rounds 缺失看决策结果补默认轮次上限5.5 几个我踩过的坑第一个坑是决策层和 Agent 抢活干。我一开始在决策层里也做了一点代码分析结果和 Agent 的分析重复了还互相矛盾。后来我把决策层的分析严格限制在路由所需的最小信息剩下的全交给 Agent。第二个坑是规则越加越多。每遇到一个边界情况就加一条规则加到三十多条的时候规则之间开始互相干扰维护成本爆炸。后来我改成规则分层核心规则不超过十条边界情况走兜底加人工确认。第三个坑是忽略决策日志。一开始我没记决策日志出了问题只能靠回忆。后来加了结构化日志每次决策记下命中的规则、输入指纹、输出结果排查效率提升非常明显。6. 这套方案还能怎么扩展6.1 接入更多执行器决策层的 target 字段现在是二选一扩展成多选很自然。只要在执行分发层加适配器决策规则里加对应的路由条件就行。我建议扩展时保持每个执行器有明确的擅长区间这个原则不要为了接入而接入。6.2 决策规则的自动化调优现在规则是手写的未来可以根据决策日志做统计哪些规则命中后经常需要人工纠正哪些规则几乎不命中。前者要改后者可以删。这一步不需要多复杂一个简单的统计脚本就能给出方向。6.3 把决策层做成可观测的服务如果团队多人共用可以把决策层做成一个轻量服务暴露一个决策接口记录所有决策日志。这样团队能看到最近哪些任务路由错了形成反馈闭环。这一步的收益在多人场景下才明显个人用可以先不做。6.4 一个我个人的小技巧最后分享一个我在实际使用中总结的小技巧给决策层加一个干跑模式。也就是只输出决策结果不真正调用 Agent。这样你在调整规则时可以快速验证如果按新规则这个任务会被路由到哪而不用真的跑一遍 Agent。这个模式帮我省了大量调试时间强烈建议你也加上。这套东西我用了几个月最大的体会是决策层的价值不在于它多聪明而在于它把怎么用 Agent这件事从人的脑子里搬到了代码里。搬出来之后它就可记录、可调优、可复用了。至于具体用哪个 Agent、哪条规则反而是次要的因为那些都可以慢慢调。
1. 为什么要在 Coding Agent 外面再套一层决策层1.1 从两个真实痛点说起先说一个我踩过的坑。去年有一段时间我同时用两个 Coding Agent 处理日常开发任务一个负责偏工程化的重构和脚本生成另一个负责偏探索性的代码理解和方案推演。用着用着就发现一个很尴尬的问题——每次遇到一个任务我得先自己判断这个活该丢给谁。判断本身不费劲但判断的过程会打断心流而且我经常判断错明明是个需要长上下文推理的活我丢给了擅长快速改文件的那个结果来回改了三轮才收敛。第二个坑更隐蔽。Coding Agent 本身是有决策能力的但它的决策是任务内决策——给定一个 prompt它决定先读哪个文件、先改哪一行、要不要跑测试。它缺的是任务前决策——这个任务到底该不该现在做、该用哪种模式做、该带多少上下文进去。这两层决策混在一起导致 Agent 经常在错误的层面上使劲。Jev 接入 Claude Code 与 Codex这件事本质上就是解决这两个坑在 Coding Agent 之上加一层快速决策能力让选谁做、怎么做、带什么进去这三件事在进入 Agent 之前就被快速定下来。Jev 在这里扮演的是决策层的角色Claude Code 和 Codex 是被调度的执行层。1.2 这层决策能力到底解决什么问题我把这层能力要解决的问题拆成三类你可以对照自己的场景看看中了几条路由问题同一个需求不同 Agent 的擅长区间不一样。有的擅长在已有代码库里做精准修改有的擅长从零生成一段独立逻辑有的擅长读大量文件后给出结论。人工路由慢且不稳定。上下文问题Agent 的表现极度依赖喂进去的上下文。喂多了它抓不住重点喂少了它瞎猜。快速决策层要能在进入 Agent 前把上下文裁剪到刚好够用。收敛问题一个任务要不要拆成多轮、每轮的验收标准是什么、什么时候该停下来问人。这些如果全交给 Agent 自己判断很容易陷入改—测—再改的循环。注意这层决策能力不是要替代 Agent 的推理而是把元决策从 Agent 内部抽出来放到一个更快、更可控、更便宜的地方。这是整个方案的核心设计哲学后面所有细节都围绕它展开。1.3 适合谁来参考这套思路如果你符合下面任意一条这篇内容对你会比较有用日常已经在用至少一个 Coding Agent但觉得每次都要自己想怎么用很累团队里多人共用 Agent希望有一套统一的调度规则而不是各凭手感想给 Agent 加一层轻量的前置处理但不想引入重型编排框架对决策层这个概念感兴趣想看看在 Coding 场景里具体怎么落地。如果你只是偶尔用 Agent 写个一次性脚本那这套东西可能有点重可以先收藏等任务复杂度上来了再回来看。2. 整体架构设计决策层与执行层怎么分工2.1 三层结构输入归一化、快速决策、执行分发我把整个链路拆成三层从上到下依次是输入归一化层把用户五花八门的输入一句话需求、一段报错、一个文件路径、一段伪代码统一成结构化任务描述。快速决策层Jev 所在层基于结构化任务描述输出一个决策结果包含目标 Agent、上下文清单、执行模式、验收标准。执行分发层把决策结果翻译成对应 Agent 能接受的调用形式分别对接 Claude Code 和 Codex。这个分层的意义在于每一层都可以独立替换。比如你以后想接入第三个 Agent只需要在执行分发层加一个适配器决策层的逻辑完全不用动。反过来你想换一套决策规则执行层也感知不到。2.2 为什么决策层要快标题里快速决策这四个字不是修辞是硬约束。原因有三个决策层在关键路径上它挡在用户和 Agent 之间它慢一秒整个交互就慢一秒。Agent 本身执行可能要几十秒但决策层如果也要几秒用户体感就是卡。决策层要便宜如果决策层本身也调用一个大模型做推理那成本就翻倍了。快速决策层应该尽量用规则、轻量分类、缓存命中来完成大部分判断。决策层要可解释Agent 内部怎么想的你很难干预但决策层必须能说清楚为什么选了这个 Agent。否则出了问题你没法调。基于这三点我在设计时定了一个原则能用规则解决的绝不上模型能用缓存命中的绝不重新计算只有真正模糊的情况才走轻量推理。这个原则后面会反复出现。2.3 决策结果的数据结构决策层的输出我定义成一个固定结构这样执行层才好对接。字段大致如下字段含义示例target目标执行器claude-code / codexmode执行模式patch / generate / explorecontext上下文清单文件路径列表、片段范围acceptance验收标准测试通过、编译通过、人工确认max_rounds最大轮次3fallback兜底策略换 Agent 重试 / 直接问人这个结构看起来简单但每个字段背后都有一堆取舍。比如mode为什么只有三种而不是更细因为模式太细会导致决策层判断负担变重三种是够用且好判断的平衡点。max_rounds为什么要有因为不加这个Agent 很容易无限循环。2.4 与直接调用 Agent 的对比为了说清楚这层决策的价值我做个对比维度直接调用 Agent加决策层路由人工判断自动判断上下文人工挑选自动裁剪成本单次调用决策开销 单次调用可解释性弱强决策可记录扩展性换 Agent 要改习惯加适配器即可可以看到加决策层唯一的代价是决策开销而这个开销通过规则化和缓存可以压到很低。收益是可解释性和扩展性这两点在长期使用中价值很大。3. 核心细节解析决策层到底怎么判断3.1 任务分类先分清改和造决策层第一步是把任务分成两大类改已有代码和造新代码。这个判断看似简单但它是后续所有决策的基础。我的判断规则是这样的如果输入里包含明确的文件路径、函数名、报错信息且这些指向的是已有代码库里的东西归为改。如果输入是帮我写一个 XXX、实现一个 XXX 功能且没有指向具体文件归为造。如果两者都有比如在 XXX 文件里加一个 YYY 功能归为改因为主体是在已有结构里动刀。为什么这个分类重要因为改和造对 Agent 的要求完全不同。改要求 Agent 能精准理解现有代码的约束造要求 Agent 能快速产出可运行的结构。Claude Code 和 Codex 在这两件事上的表现差异是路由决策的主要依据。3.2 上下文裁剪给多少才刚好上下文裁剪是决策层里最容易被低估的一环。我见过太多人直接把整个仓库丢给 Agent然后抱怨 Agent 抓不住重点。实际上Agent 的注意力是有限的喂太多等于没喂。我的裁剪策略分三步锚点定位从输入里提取锚点比如报错的文件名、函数名、行号。锚点是裁剪的起点。扩散范围从锚点向外扩散扩散范围取决于任务类型。改任务扩散到调用方和被调用方造任务扩散到同类实现作为参考。预算控制给上下文设一个 token 预算超了就按相关性排序截断。这里有个经验值可以参考对于改任务上下文控制在 2000 到 8000 token 之间通常比较合适对于造任务参考实现的上下文控制在 3000 token 以内剩下的留给生成。这个数字不是绝对的但可以作为起点。提示裁剪的时候宁可少给一点让 Agent 主动去读也不要一次给太多。Agent 主动读文件的过程本身就是在建立理解这个理解比被动接收上下文更扎实。3.3 模式选择patch、generate、explore 的适用边界三种模式的边界我总结如下patch 模式适用于明确的局部修改。特征是改动范围可预期、验收标准明确比如测试通过。这种模式要求 Agent 输出 diff 而不是完整文件减少出错面。generate 模式适用于从零生成或大范围重写。特征是现有代码参考价值低、需要 Agent 自由发挥。这种模式允许 Agent 输出完整文件。explore 模式适用于我还不确定要改什么的情况。特征是任务描述模糊、需要先理解再动手。这种模式让 Agent 先输出分析报告人确认后再进入 patch 或 generate。模式选错的代价很大。我试过把本该 explore 的任务当成 patch 丢进去结果 Agent 在没理解全局的情况下改了一堆文件最后全回滚了。所以决策层在模式判断上要保守一点拿不准的时候先 explore。3.4 验收标准怎么定义做完了验收标准是决策层里最容易被忽略但最重要的一环。没有验收标准Agent 就不知道什么时候该停人也不知道该不该接受结果。我的验收标准分四级级别标准适用场景L1编译/语法通过任何代码改动的最低要求L2相关测试通过有测试覆盖的模块L3新增测试通过新增功能L4人工确认涉及设计决策的改动决策层要根据任务类型自动选一个级别。比如纯格式化改动 L1 就够新增功能至少要 L3。这个级别会写进决策结果执行层据此判断是否继续。4. 实操过程从零搭起这套决策链路4.1 环境准备与依赖梳理先说环境。这套东西对运行环境要求不高核心依赖就几样一个能跑脚本的运行时我用的是 Python你也可以用 Node两个 Agent 的调用入口Claude Code 和 Codex 各自的命令行或 API一个轻量的规则引擎其实用配置文件加 if-else 就够不用上重型框架一个缓存层本地文件缓存即可不用上 Redis。我特意把依赖压到最低因为决策层本身应该是透明的依赖越多越容易出问题。你如果只是想验证思路甚至可以先不接真实 Agent用 mock 把决策链路跑通再说。4.2 输入归一化的实现输入归一化这一步我写了一个简单的解析器把输入映射成结构化任务。核心逻辑如下def normalize(raw_input): task { raw: raw_input, anchors: extract_anchors(raw_input), # 文件路径、函数名、报错 intent: classify_intent(raw_input), # fix / create / explore scope: estimate_scope(raw_input), # local / module / repo } return taskextract_anchors用正则匹配文件路径和常见报错格式classify_intent用关键词加简单规则estimate_scope根据锚点数量和是否提到全局重构这类词来判断。这里有个细节不要在这一步做太重的 NLP。归一化的目标是够用不是完美。我一开始想用模型做意图分类后来发现规则能覆盖 80% 的情况剩下 20% 走兜底就行没必要为了 20% 把整条链路拖慢。4.3 决策规则的编写与优先级决策规则我用一个有序列表来组织从上到下匹配命中即停。大致长这样如果 intent 是 explore直接选 explore 模式目标 Agent 选擅长长上下文理解的那个。如果 intent 是 fix 且 scope 是 local选 patch 模式目标 Agent 选擅长精准修改的那个。如果 intent 是 create 且 scope 是 module选 generate 模式。如果 scope 是 repo无论 intent 是什么先降级为 explore因为大范围改动风险太高。兜底选 explore 模式让 Agent 先给分析。这个顺序很重要。风险高的规则要排在前面比如第 4 条大范围改动降级必须早于具体的 fix/create 判断否则会被后面的规则覆盖掉。4.4 对接 Claude Code 与 Codex 的适配层适配层的职责是把决策结果翻译成各 Agent 能接受的调用。两个 Agent 的接口形态不一样所以适配层要分别处理。对接 Claude Code 时我主要用它处理 patch 和 explore 模式因为它在理解现有代码结构上比较稳。调用时把 context 清单转成它认识的路径参数把 acceptance 转成它执行后要跑的验证命令。对接 Codex 时我主要用它处理 generate 模式因为它在从零产出结构上比较快。调用时把 context 作为参考片段传入把 max_rounds 作为它的重试上限。适配层的关键是把决策结果里的抽象字段翻译成具体参数。这一步不要偷懒翻译逻辑要写清楚否则出了问题你根本不知道是决策错了还是翻译错了。4.5 缓存与命中策略缓存是让决策层快起来的关键。我缓存两类东西任务指纹到决策结果的映射把归一化后的任务算一个指纹命中就直接返回上次的决策。锚点到上下文的映射同一个文件同一个函数裁剪出来的上下文基本一样可以复用。缓存失效策略我用的是文件修改时间 任务指纹双条件。文件没改、任务一样缓存就有效。实测下来重复任务的决策耗时能从几百毫秒降到几毫秒。注意缓存不要缓存决策过程只缓存决策结果。过程缓存会导致你调试时看到的是旧逻辑很容易误判。5. 常见问题与排查技巧实录5.1 决策层选错 Agent 怎么办这是最常见的问题。表现是任务丢给了 AA 做了一半卡住换 B 才做完。排查思路是回看决策记录看是哪条规则命中了、为什么命中。我遇到过的典型原因是锚点提取失败。比如输入里写的是那个处理用户登录的地方没有具体文件名锚点提取为空决策层只能走兜底规则。解决办法是在归一化层加一个模糊锚点处理如果提取不到精确锚点就用关键词去代码库里搜搜到候选再让用户确认。5.2 上下文给多了导致 Agent 跑偏表现是Agent 读了一堆无关文件然后在一个不相关的地方改了东西。排查时看决策结果里的 context 清单如果清单长度明显超过预算就是裁剪没生效。原因通常是扩散范围设太大。我的经验是扩散范围默认只扩一跳也就是只包含直接调用方和被调用方不要递归扩散。需要更多上下文时让 Agent 自己主动去读而不是一次性喂给它。5.3 验收标准太松导致反复返工表现是Agent 说做完了你一测发现没做完。排查时看决策结果里的 acceptance 级别如果任务明显需要 L3 但决策给了 L1就是级别判断错了。修正方法是在决策规则里加一条只要任务涉及新增逻辑acceptance 至少 L3。这条规则能挡掉大部分假完成。5.4 常见问题速查表现象可能原因排查动作解决方向选错 Agent锚点提取失败看决策记录加模糊锚点处理Agent 跑偏上下文超预算看 context 清单缩小扩散范围反复返工验收标准太松看 acceptance 级别提高级别下限决策变慢缓存未命中看缓存命中率优化指纹算法无限循环max_rounds 缺失看决策结果补默认轮次上限5.5 几个我踩过的坑第一个坑是决策层和 Agent 抢活干。我一开始在决策层里也做了一点代码分析结果和 Agent 的分析重复了还互相矛盾。后来我把决策层的分析严格限制在路由所需的最小信息剩下的全交给 Agent。第二个坑是规则越加越多。每遇到一个边界情况就加一条规则加到三十多条的时候规则之间开始互相干扰维护成本爆炸。后来我改成规则分层核心规则不超过十条边界情况走兜底加人工确认。第三个坑是忽略决策日志。一开始我没记决策日志出了问题只能靠回忆。后来加了结构化日志每次决策记下命中的规则、输入指纹、输出结果排查效率提升非常明显。6. 这套方案还能怎么扩展6.1 接入更多执行器决策层的 target 字段现在是二选一扩展成多选很自然。只要在执行分发层加适配器决策规则里加对应的路由条件就行。我建议扩展时保持每个执行器有明确的擅长区间这个原则不要为了接入而接入。6.2 决策规则的自动化调优现在规则是手写的未来可以根据决策日志做统计哪些规则命中后经常需要人工纠正哪些规则几乎不命中。前者要改后者可以删。这一步不需要多复杂一个简单的统计脚本就能给出方向。6.3 把决策层做成可观测的服务如果团队多人共用可以把决策层做成一个轻量服务暴露一个决策接口记录所有决策日志。这样团队能看到最近哪些任务路由错了形成反馈闭环。这一步的收益在多人场景下才明显个人用可以先不做。6.4 一个我个人的小技巧最后分享一个我在实际使用中总结的小技巧给决策层加一个干跑模式。也就是只输出决策结果不真正调用 Agent。这样你在调整规则时可以快速验证如果按新规则这个任务会被路由到哪而不用真的跑一遍 Agent。这个模式帮我省了大量调试时间强烈建议你也加上。这套东西我用了几个月最大的体会是决策层的价值不在于它多聪明而在于它把怎么用 Agent这件事从人的脑子里搬到了代码里。搬出来之后它就可记录、可调优、可复用了。至于具体用哪个 Agent、哪条规则反而是次要的因为那些都可以慢慢调。
