别再让AI每次“重新找路”了!

你的 agent 每次都在重新找路。一个大 prompt 走天下的日子，该结束了。

去年到今年，我看过不少团队的 agent 项目（内部评审、开源代码、朋友发来的 trace），有一种模式出现的频率高得离谱：一个巨大的 system prompt，塞满了角色设定、规则、工具说明、各种 if-else 的自然语言版本。然后给 agent 一大堆工具，权限全开，让它自己看着办。

demo 效果通常不错。第一次跑通的时候，团队会很兴奋。然后开始出问题。某个边缘 case 挂了，往 prompt 里加一段规则。模型升级之后行为变了，再加一段。某天改了一行，三个星期之后发现另一个场景坏了，回头查，就是那次改动干的。

prompt 越长，情况越糟。这不是玄学——今年 9 月一个开发者meetup 上，好几个演讲者独立提到了同一个观察：上下文用到 70% 左右，输出质量不是线性下降，是断崖。还有多人报告，CLAUDE.md 这类系统提示文件持续膨胀之后，不光烧 token，模型表现本身就变差了，因为多出来的指令在互相抢注意力。

博客作者 adlrocha 最近写了一篇把这事说得很透的文章。他的原话大意是：很多看起来是 prompt 问题的问题，其实是架构问题。

他给这两种形态起了名字，我觉得挺准的。

胖 agent：一个助手，一个大目标，一个巨大的上下文窗口，你能想到的工具全给它，接下来怎么走它自己定。

窄 agent：把流程切成若干个有边界的工作单元——路由、资格检查、实现、验证、评审。每个单元有明确的输入输出约定，只拿它干活所需的最小上下文，只开它需要的最小权限。

胖 agent 的唯一优势是快。demo 好看，出活快，这是它流行的主要原因。但窄 agent 有一个胖 agent 永远给不了的东西：可测试性。

一个窄单元「找出改动代码里的正确性问题」，你可以给它建测试集，量出 precision、recall、延迟、成本、人工一致性。换了一个模型，你能确切知道这一块是变好了还是变坏了。胖 agent 做不到，它每次执行路径都不一样，你连回归测试都没法写。

这是整篇文章里我最想让你带走的一个念头。

你用一个大 prompt 让 agent 解决了某个任务。读一遍 trace：它拉了这三份文档，检查了那个条件，跑了测试，按某个格式输出了结果。路已经找到了。那你为什么要它在下一次运行时从头再找一遍？同样的 token 再付一次，还附带一个全新的跑偏机会。

adlrocha 的比喻很刻薄但很形象：你已经找到了梯度下降的低点，然后每次做这个任务，都重新付一遍下山的钱。他说这种实现在生产系统里到处都是。信他，也信你自己要是翻过自己团队的 trace 的话。

当然要公平地说一句：胖 agent 不是错的，它有它的位置。你还不清楚一个问题该怎么解的时候，就需要一个能闲逛、上下文宽、工具多的 agent 去探索，它经常能找到人想不到的路线。开放性问题、一次性任务、要创意的场景，大 prompt 加技能目录是对的选择。

分界线在「可重复」。一个任务你只做一次，让它自由发挥。一个任务你每周要做两百次，那就别再让它探索了——把 trace 里的路径固化下来。

拿一个真实场景走一遍。假设你的胖 agent 在做「用户反馈分类并路由给对应团队」，每次运行都要读完整的产品背景文档、全部规则，然后自己决定分类标准和路由逻辑。

改造步骤大概是这样：

第一步，读 trace，画出实际路径。 别凭想象，真的去读执行记录。十次运行之后你会发现，它的实际行为收敛在少数几条路径上。分类逻辑、路由规则，翻来覆去就那几套。

第二步，把高频路径切成工作单元。 「解析反馈 → 判断类别 → 匹配负责团队 → 生成摘要」四个阶段。每个阶段定义输入输出：进来的字段是什么，出去的字段是什么。

第三步，能写死代码的就写死代码。 adlrocha 有一条原则值得贴在工位上：模型用在模糊性下的判断，确定性代码用在权限、路由、校验和一切要接触真实世界的东西上。类别到团队的映射表是一个 dict，不需要大模型。正则能提取的字段，别让模型生成 JSON。

第四步，每个单元给最小上下文。 Google Cloud 的开发者布道师 Guillaume Laforge 在播客里讲过，子 agent 用窄上下文是有意为之的设计：一个验证 schema 的 agent 不需要产品路线图。隔离同时带来更好的专注和更低的 token 成本。分类单元只需要类目定义和当前这条反馈，别的不给。

第五步，加检查点和重试。 Inngest 最近那篇讲 durable agents 的文章列了 agent 在生产里的五种死法，其中一个共同解药是：每步之后持久化进度，崩了从检查点恢复，而不是从头再来。配合幂等设计，一个 45 分钟的任务才敢中途挂。

改完之后效果是三层的：单次成本降了（窄上下文加命中缓存），稳定性升了（每个单元可独立测试），出问题能定位（坏在哪个单元一目了然，而不是面对一坨成功了一半的 trace 发呆）。

安全这个点上有个坑值得知道。有人记录过一次真实事故：文件系统权限挡住了 agent 的 DELETE 操作，agent 转手把文件内容清空了，效果一样。规则挡住了一条路，它找了另一条。这说明两件事：一，窄 agent 的权限设计要按「单元」给，而不是按「操作」给——路由单元根本不该有写权限。二，关键流程的校验要落在确定性代码上，模型的「自觉」不能当安全边界。这个和我们昨天聊的自然语言规则没有强制兜底的问题，是同一个根。

三个里中一个就够：同一个 prompt 文件超过三个月没删过东西，只往里加过；每次 agent 行为怪异，团队的反应是「再补一段提示词」；你说不出上个月那次模型切换，对任务成功率的具体影响。

发现路径 → 固化路径 → 切单元 → 写死能写死的。就这一条线。改造成本不高，从一个你跑得最勤的任务开始就行。