GitHub每日热评不只是系统提示词dsh-routing-suite 如何用协议和指标约束 Agent 行为本文基于yjh051108/dsh-routing-suite指定仓库快照e3f00b24db44进行分析。项目许可证为 MIT目标依赖版本为DSH 0.1.0-rc.6 0.2.0。文中关于实验效果的内容来自项目文档本文未复跑其完整实验集。作者Valhalla Matrix治理实验室评测方式证据驱动·只读静态源码审阅无运行时执行结论可复现很多 Agent 项目的优化方式最后都会回到同一个动作修改 system prompt ↓ 运行几次任务 ↓ 感觉模型更认真了这种方法可以快速试错但很难回答几个关键问题模型究竟在哪个阶段开始偷懒任务后半段的工具调用是否明显减少修改协议后模型的行为是否真的发生变化不同模型使用同一套提示词效果是否一致一次成功的任务能不能被别人复算dsh-routing-suite的思路有所不同。它并不只提供一段更长的系统提示词而是围绕 DSH 运行环境提供运行时注入、任务感知路由和分级任务协议并配套会话 JSONL 的测量工具。它试图把 Agent 的“勤勉程度”从主观感受转换成可观察指标运行时行为 ↓ 会话日志 ↓ 指标提取 ↓ 任务前后对照这类方法未必能证明模型一定变得更强但至少让讨论从“我感觉有效”向“哪些行为发生了变化”迈了一步。一、先理解它要解决的问题长程 Agent 任务通常包含多个阶段理解需求 ↓ 读取资料 ↓ 制定计划 ↓ 调用工具 ↓ 检查中间结果 ↓ 修正问题 ↓ 完成交付在任务早期模型往往会认真分析上下文、读取文件并调用工具。任务进入后半段后可能出现一些可观察的问题跳过必要的文件读取减少工具调用直接假设结果正确没有完成终验就宣布任务结束只执行最短路径没有对失败步骤进行复核。这些现象不能简单归因于“模型变懒”。它们也可能来自上下文过长任务目标不够明确工具描述不清晰中间状态没有持久化评价指标只看最终文本协议要求没有被结构化表达。dsh-routing-suite选择的解决方向是在 Agent 运行过程中增加一层协议和路由机制对不同任务阶段施加不同约束并用会话日志进行事后分析。二、项目提供的三类能力从仓库结构和文档来看项目主要由三部分组成组件主要职责injector管理运行时注入、热重载、卸载和路由恢复preset提供不同的路由预设和模型行为配置graded用分级任务协议约束计划、执行、验收和审计三者分别位于不同层面。injector如何接入运行时 preset不同任务如何路由 graded任务过程如何执行和验收这比把所有行为规则塞进一段 system prompt 更容易拆分和观察但也意味着系统复杂度增加了。三、Injector运行时注入带来的灵活性与风险项目中的injector主要负责运行时管理能力包括注入配置热重载卸载侧挂路由转正路由异常后的恢复。它解决的是配置变化问题。传统方式可能需要修改配置 ↓ 停止 Agent ↓ 重新启动 ↓ 加载新配置运行时注入则希望缩短反馈周期修改配置 ↓ 重新注入 ↓ 继续运行或重新测试对于实验阶段这种方式很方便。研究者可以快速比较不同路由、不同预设和不同任务协议而不必频繁重启整个环境。但运行时修改也会扩大故障范围。需要重点关注注入是否影响已经开始的任务热重载后旧配置是否完全清理卸载失败时是否会残留状态路由恢复是否可能重复执行多个插件同时注入时执行顺序如何确定日志能否还原某次任务实际使用了哪一版配置。因此运行时注入不应该默认用于唯一的生产 Agent。更稳妥的测试顺序是独立测试环境 ↓ 复制会话 ↓ 短任务验证 ↓ 长任务验证 ↓ 灰度运行 ↓ 生产环境四、Preset路由规则不是越多越好项目提供了类似以下的预设router-standard router-spec其基本思路是根据任务类型、模型角色或当前执行阶段选择不同的行为路由。可以抽象成输入任务 ↓ 识别任务类型 ↓ 选择路由预设 ↓ 注入对应协议 ↓ 执行任务例如不同任务可能需要不同的约束重点任务类型更关注的行为信息检索是否读取来源、是否保留引用代码修改是否检查现有代码、是否运行测试文件处理是否逐项确认输入和输出长流程任务是否保存计划、是否进行中间复核高风险操作是否经过确认和终验路由的价值在于减少“一套提示词覆盖所有任务”的粗糙做法。但路由系统也有一个常见风险规则越来越多最后没人知道到底是哪一条规则改变了模型行为。因此实际使用时建议记录任务类型 路由名称 协议版本 注入时间 模型版本 工具集合 最终输出 会话指标如果缺少这些信息出现效果变化后就很难定位原因。五、Graded把长程任务拆成可检查的阶段项目中更有辨识度的部分是graded协议。从文档描述看它把任务拆分为多个阶段提出问题 ↓ 规格化计划 ↓ 执行与打卡 ↓ 任务收官 ↓ 最终验收 ↓ 审计记录这种设计的核心不是让模型生成更多文字而是要求它在任务过程中留下可验证的状态。一个抽象示例可以是{task:整理项目文档并生成报告,plan:[读取项目目录,识别关键文件,提取配置和测试信息,生成报告,检查报告中的事实引用],checkpoints:[{name:读取项目目录,status:done},{name:检查事实引用,status:pending}],final_verification:{status:pending}}这里真正有用的是状态而不是格式本身。如果任务最终失败可以进一步判断是计划没有制定 是工具没有调用 是中间检查被跳过 还是最终验收没有执行相比只检查最终答案这种分阶段协议更适合分析长流程任务。六、什么叫“模型偷懒”“模型偷懒”是一个容易被滥用的说法。如果没有明确指标它可能只是人的主观评价。要把它变成可分析的问题就需要定义可观察行为。例如可以关注每个阶段的工具调用次数关键文件的读取次数计划项完成比例失败后的重试次数中间检查是否执行最终验收是否执行任务后半段的行为密度输出与实际工具结果是否一致。可以定义一些简单指标。1. 工具调用覆盖率工具调用覆盖率 实际调用过的必要工具数 / 任务要求的必要工具总数2. 检查点完成率检查点完成率 已完成检查点数量 / 计划中的检查点总数3. 终验执行率终验执行率 执行最终验证的任务数 / 完成任务总数4. 后半程行为衰减可以将任务分为前半段和后半段比较两部分的工具调用密度后半程工具调用密度 后半段工具调用次数 / 后半段交互步数如果这个指标持续下降同时关键步骤遗漏率上升才有理由进一步研究是否存在长程执行衰减。需要强调的是这些指标只能描述行为不能单独证明模型“认真”或“不认真”。行为减少也可能是因为任务已经进入无需工具的阶段。七、项目如何通过会话 JSONL 进行测量项目提供了类似下面的测量命令nodescripts/measure.mjs your-session.jsonl从设计上看它的输入是 Agent 会话日志输出经过脱敏的统计结果。JSONL 适合作为这种分析格式因为每一行都可以对应一个事件{type:task_start,task_id:demo-001}{type:tool_call,name:read_file,path:README.md}{type:checkpoint,name:read_project_files,status:done}{type:tool_call,name:run_tests}{type:task_end,status:success}基于这样的事件流测量工具可以统计任务持续时间 工具调用次数 检查点完成情况 任务阶段分布 终验是否执行 不同会话之间的差异这类工具的工程价值在于它可以让评测从手工阅读日志变成批量分析。例如比较两组会话A 组不使用 graded 协议 B 组使用 graded 协议然后比较指标A 组B 组必要工具调用覆盖率检查点完成率终验执行率任务成功率平均任务时长人工返工次数只有同时观察质量和成本才知道协议是否真正有用。八、如何看待项目中的 P1-P23 实验结论仓库文档提到了一组 P1-P23 的测试或任务实验。文章中引用这类编号时需要注意几个问题P1-P23 的具体任务定义是什么样本量有多大使用了哪些模型是否控制了 prompt 和工具环境对照组和实验组是否只有一个变量不同成功标准是人工判断还是自动指标是否公开了原始会话是否存在失败样本结论能否推广到其他模型。如果这些条件没有完全公开就不应该把“P1-P23 实测”改写成普遍性结论。更准确的表达方式是项目文档提供了 P1-P23 的实验口径和对照结果说明作者尝试用任务集评估协议效果。但在没有独立复跑、扩大样本和跨模型验证之前这些结果更适合作为项目内部观测而不是通用性能结论。这是技术评测中非常重要的边界。九、安装与目录布局注意事项项目支持通过 DSH 插件命令安装例如dsh plugin--profile web add github:yjh051108/dsh-routing-suite仓库还提供了install.ps1用于装配注入器、复制预设和执行目录检查。其中一个容易踩坑的地方是目录层级。文档特别提醒不要把整个preset目录直接复制到.agent-presets。如果形成了多余的一层目录可能变成.agent-presets/preset/router-standard而 DSH 期望的结构可能是.agent-presets/router-standard当扫描器只检查一级子目录时前一种结构就可能无法被发现。这类问题看起来只是路径错误但它说明插件系统中的“安装成功”和“运行时成功”是两件事文件复制成功 不等于 插件已被扫描 不等于 路由已被加载部署完成后建议检查预设目录是否位于 DSH 扫描路径目录名称是否符合约定注入器是否被正确加载当前会话使用的是哪一个预设热重载后配置是否生效卸载后是否仍有残留规则。十、最大风险依赖 DSH Developer Preview项目目标依赖版本为DSH 0.1.0-rc.6 0.2.0这表明它依赖的是仍处于 Developer Preview 阶段的运行环境。预览版依赖的主要风险包括插件接口可能变化目录扫描规则可能变化注入生命周期可能变化路由字段可能发生 breaking change原有插件在升级后无法加载文档和实际行为可能暂时不一致。仓库中的preset/CHANGELOG.md还记录了多个预发布版本例如rc.8 0.1.1-rc.2 0.1.2-alpha.1在生产环境中不建议直接使用浮动版本。更稳妥的方式是锁定 DSH 版本 锁定插件提交 保存配置快照 建立回滚方案同时为关键任务保留一组固定会话用于升级后的回归比较。十一、为什么不建议同时安装多个行为插件文章中提到的dsh-anchored-standard更偏向于通过 Minimal 条件锚定首轮推理轨迹而dsh-routing-suite重点关注任务路由和长程执行协议。两者并非一定冲突但同时启用时会出现一个实际问题到底是哪一个插件改变了模型行为尤其是多个插件都可能修改以下内容system promptdeveloper message工具调用约束任务状态路由字段会话生命周期首轮执行策略。因此进行实验时最好采用单变量方式基线环境 ↓ 只启用插件 A ↓ 恢复基线 ↓ 只启用插件 B ↓ 恢复基线 ↓ 启用 AB 并记录组合效果每次测试都保存插件列表 插件版本 配置文件 模型版本 任务输入 会话日志 测量结果否则最终只能看到“组合后的行为变化”无法解释具体原因。十二、如何设计一套更可靠的验证实验如果准备在自己的 Agent 中测试该项目可以从一个小型实验开始。实验目标验证协议是否降低了长任务中的关键步骤遗漏。实验变量项目基线组协议组模型相同相同任务相同相同工具相同相同最大步数相同相同任务协议不启用启用路由默认指定 preset任务样本准备 10 到 20 个具有明确检查点的任务例如读取多个源文件后生成报告修改代码并运行测试分析数据后输出结论处理一组文档并进行完整性检查调用多个工具完成部署前检查。观察指标任务成功率 关键步骤遗漏率 工具调用覆盖率 终验执行率 人工返工次数 平均任务时长 Token 消耗结果解释如果协议组的检查点完成率更高但任务时长和 Token 消耗明显增加那么它可能适合高可靠任务却不适合追求低成本的简单任务。如果协议组工具调用次数增加但最终正确率没有提高则说明协议可能增加了形式化动作却没有改善实际质量。这比只统计“调用次数变多了”更加可靠。十三、它适合什么不适合什么适合已经使用 DSH 运行长程 Agent 任务的团队需要记录和分析 Agent 行为的人想比较不同路由和协议效果的开发者对会话 JSONL、审计和回归测试有要求的系统需要提高关键检查点完成率的自动化流程。不适合直接用于只需要一句话问答的简单任务还没有稳定日志格式的 Agent没有明确任务成功标准的场景对运行时修改风险敏感的生产系统需要长期稳定接口但无法锁定 DSH 版本的项目只想复制一段提示词就获得普适效果的使用者。它并不是万能的模型增强器更像是一套实验和运行时控制工具。结语把“模型变认真”改写成可以验证的问题dsh-routing-suite最值得关注的地方不是它提供了多少条提示词而是它试图建立一条可复核链路任务协议 ↓ 运行时路由 ↓ 会话事件 ↓ 行为指标 ↓ 对照实验这让一个模糊的问题变得更具体模型是不是更认真了可以被拆成是否读取了必要文件 是否调用了必要工具 是否完成了计划中的检查点 是否执行了最终验收 后半程是否出现行为衰减 协议带来的额外成本是多少当然项目仍然存在明显边界依赖 DSH Developer Preview运行时注入可能影响现有会话P1-P23 等实验结果尚未在本文中独立复跑行为指标不能直接等同于任务质量更严格的协议可能增加 Token、工具调用和执行时间多个插件同时使用时归因会变得困难。因此比较准确的定位是dsh-routing-suite不是一段更长的 system prompt而是一套围绕 DSH 的运行时路由、任务协议和会话测量工具。如果你的 Agent 已经能够稳定输出 JSONL并且你确实遇到了长任务后半段检查不足、工具调用减少或终验缺失的问题那么这个项目值得进行小规模对照实验。实验开始前先定义成功标准实验结束后再根据日志判断协议是否有效。不要因为模型多输出了几段计划就直接得出“Agent 变可靠了”的结论。
