QBR Q2 · forge · 田东生

把 forge 的工具供给,从「启动全量注册 + 静态大提示词」重构为「skill-based pack + manifest 按需加载 + 动态系统提示词」

一次架构判断:把"模型一次需要看见多少工具"作为切分依据,并用 eval 验证它没有让模型选错工具。

关键决策

工具数量增长后,我没有继续往扁平的 forge-tools.factory 堆工具,而是按能力域/业务域切成 pack(各自 manifest + SKILL.md 作为单一真值源),运行时按场景 load-pack 按需加载,system prompt 动态拼装,pack 之间用 dependsOn 自动闭包补齐依赖。

当时的备选方案

B1全量静态引导:全部工具一次性注册,靠一个手写的静态 prompt 逐个引导模型何时用哪个工具。改动成本最低,但 prompt 无限膨胀、易漂移、难维护。

B2静态分组:按固定场景把工具预先分成几组,但分组写死、不做动态加载。比一个大 prompt 强,但加新场景要手改,扩展性受限。

选定动态按需加载:运行时按场景动态拼装该看的工具子集 + 动态 prompt,pack 间用 dependsOn 自动闭包补齐依赖。为命中率和可扩展性付一次性重构成本,换长期边际成本下降。

选择依据,以及最大风险怎么提前验证

技术约束

上下文预算是硬墙:工具一多,全量注册会把工具 schema + system prompt 顶爆上下文。这和我同期做的 token budget、长会话压缩是同一约束的两面。

可维护性与正确性

说明散在 prompt 里必然漂移,改成 SKILL.md 单一真值源后"加能力等于加 pack"。dependsOn 自动闭包保证加载 A 必带依赖 B,堵住漏加载导致的半截失败。

最大风险 + 提前验证

风险是按需加载后模型可能加载不到或选错工具,等上线才暴露就晚了。所以我建 eval,把最严的一档确定性硬约束(审核中写回、越权、先读后写顺序等红线)接入 CI 门禁,把验证前移。

结果:用 eval 验证效果

为保证重构后的效果,我把模型行为沉淀成一套可回归的 eval:对真实 LLM 做黑盒测试,逐条检查 agent 是否守住业务红线(审核中只读、不可越权写、先读后写顺序等)。重构后用它跑回归,再对失败逐条复盘——区分出哪些是模型随机性、哪些是 agent 真违反了约束。

我学到的:

agent 架构改动靠"上线看反馈"来验证太慢、也不准;把预期行为写成 eval,才能在重构这种高风险动作上先验证再动手,而它确实在上线前帮我拦下了真问题。
eval 本身也要写得稳:agent 的回答带随机性,断言若要求它严格按某个工具顺序执行,换一条同样合理的路径就会被误判,真正的问题反而被这些误报盖住。
更底层的一条:agent 的工具供给本质是上下文预算问题,不是功能堆叠问题——架构要按"模型一次需要看见多少"来切,而不是按代码模块切。

下季度:重复 / 停止 / 改变各一条

重复:高风险重构前,先把模型行为落成一套可回归的 eval,再动架构——先验证、再动手。

停止:停止把 eval 断言写死成"必须严格按某个工具顺序",改用"几条可接受的路径都算通过"的判定。

改变:把 SKILL.md 从"只喂 prompt",改成一处定义、同时驱动 prompt、文档和 eval——彻底消除三者之间的漂移。