AI Agent 开发别过度设计：LLM 已搞定路由

过去两年里，我一直在构建用于生产环境的 AI Agent。不是 demo，也不是周末项目，而是真实用户每天都会与之交谈、出现故障时会让用户恼火的系统。

我反复看到的一种模式是什么？工程师们围绕模型搭建了一套套复杂的机器：自定义编排层、手写的重试逻辑、庞大的工具路由系统。所有这些，都是为了解决一些本来只要放手让 LLM 去做，它自己就能解决的问题。

如果能回到过去，下面这些东西就是我会删掉的。

1. 自定义工具选择逻辑

你构建了一个分类器，用来决定 Agent 应该使用哪个工具。也许是基于正则表达式的路由器，也许还要单独调用一次模型，只为了选出正确的函数。

只要为现代 LLM 提供命名合理、描述清晰的工具，它们在工具选择方面的表现好得惊人。问题从来不在模型，而在你的工具描述。

// Bad: vague tool name, model guesses wrong
{ name: "search", description: "Searches for things" }

// Good: specific name, clear scope, model nails it
{ name: "search_customer_accounts", description: "Search customer accounts by account ID, customer name, or date range. Returns subscription status, plan details, and usage history." }

解决方案不是更聪明的路由器，而是更好的工具设计。给工具命名时，把它当成在为一个从没见过你代码库的初级开发者编写 API。描述得再具体都不为过。

即使工具选择指标看起来非常出色，最终答案仍然可能是一堆垃圾。这是我亲眼见过的情况：Agent 有 95% 的概率选对工具，却依然给出错误答案，因为工具描述并没有解释返回的数据究竟意味着什么。

2. 用于多步推理的 Prompt 链

过去，只要遇到复杂任务，我就会构建包含 4～5 个步骤的 prompt 链：拆解问题，把输出 A 传给 prompt B，解析结果，再把它传给 prompt C。

后来我发现，只需要一个结构良好、指令清晰的 system prompt，就能原生处理其中的大多数任务。模型本来就知道如何拆解问题。你只需要告诉它有哪些约束，以及优秀的输出应该是什么样子。

// Instead of chaining 3 prompts:
// 1. "Classify the user intent"
// 2. "Based on intent X, gather context"
// 3. "Now generate the answer"

// Just do this:
const systemPrompt = `You are a support agent for a SaaS platform.

When a user asks a question:
1. Identify whether they need account info, billing help, or technical support
2. Use the appropriate tool to get the data
3. Answer in plain English with the specific details they asked for

If you're unsure about intent, ask one clarifying question. Never guess.`

链式方案还会制造一个隐藏的问题：每一步都是潜在的故障点。当一个四步链在第三步出错时，调试过程会非常痛苦。相比之下，一个指令清晰的 prompt 更容易观察、更容易评估，失败时也能更优雅地应对。

3. 在检索质量之前堆砌检索复杂度

这一点很扎心，因为我自己也这么做过。

你花两周时间构建了一套混合检索流水线：BM25 加向量搜索，再加重排序。架构非常漂亮，画在图里也赏心悦目。

然后你意识到，真正的问题是知识库文档的写法让模型根本无法解析。或者你的分块策略把答案拆到了两个 chunk 里，导致任何一个 chunk 单独拿出来都说不通。

如果底层数据一团糟，检索流水线再好也没有意义。

在优化搜索算法之前，先问问自己：

如果我把这个 chunk 直接展示给一个不了解任何上下文的人，他能看懂答案吗？

我的文档究竟是写给模型看的，还是写给原作者自己的大脑看的？

我是按照逻辑边界分块，还是机械地每 500 个 token 切一刀？

我见过一些团队，他们的检索已经“正常工作”，但答案仍然是错的，因为参考数据本身包含过时或错误的信息。这不是检索问题，而是一个披着检索外衣的数据质量问题。

4. 阻碍正常使用的自定义 Guardrail

你构建了一个内容过滤器，它能拦截不良输入。很好。

然后用户开始抱怨，正常问题也会被拦截。有人询问“终止合同”，guardrail 就因为“终止”而触发。有人询问指标中的“爆炸式增长”，结果又触发了另一个过滤器。

大规模使用基于规则的 guardrail，最终会变成一场永远赢不了的打地鼠游戏。

LLM 本身已经非常擅长理解意图和上下文。与其在模型外面砌一堵正则表达式墙，不如把 guardrail 写进模型的指令里。告诉它哪些话题禁止涉及，哪些信息绝对不能泄露；告诉它应该自然地引导用户，而不是生硬地拒绝沟通。

// Instead of: regex filter that blocks "kill", "terminate", "destroy"
// Try this in your system prompt:

`If a user asks about topics outside your domain (account management and billing),
politely redirect them. Never share internal system details, API keys,
or other customer data. You can decline requests, but always explain why
and suggest what you CAN help with.`

Guardrail 和权限属于产品设计，而不只是安全表演。请用产品设计的方式认真对待它们。

5. 把 Agent Memory 做成独立系统

你的 Agent 数据库放在这里，memory 系统放在那里，向量数据库又放在另一个地方。连接这一切的胶水代码，只能靠祈祷和 setTimeout 勉强维持。

真正的问题其实比你构建的架构简单得多：Agent 在不同会话之间究竟需要记住什么？

大多数 Agent 并不需要复杂的 memory 系统。它们需要的是一个结构良好的上下文窗口：对话历史，再加上少量与用户有关的关键信息。就这些。剩下的交给模型处理。

当你确实需要持久化 memory 时，让它尽量靠近你的数据。不要构建一个必须与数据库同步的独立 memory 服务。数据存在哪里，memory 就存在哪里；查询时也使用同一套工具。

一旦 Agent 的 memory 无法访问它自己的数据库，你就制造了一个伪装成功能的集成问题。

6. 什么都用 Sub-Agent 编排

多 Agent 架构非常诱人。一个 Agent 负责规划，一个负责检索，一个负责生成，一个负责验证。它们通过消息总线互相通信。画在白板上，看起来非常惊艳。

但到了生产环境，它就是一场调试噩梦。答案错了，究竟是哪个 Agent 出了问题？规划 Agent？检索 Agent？还是生成 Agent？明明一个 Agent 就能解决，你最终却不得不构建一套可观测性工具，只为追踪四个 Agent 之间究竟发生了什么。

从一个 Agent 开始。不断推进，直到它确实无法处理当前的复杂度。只有到了那个时候，才把它拆分成职责清晰、范围狭窄的专业 Sub-Agent。

我遵循的规则是：只有当父 Agent 的上下文窗口确实装不下完成任务所需的信息时，Sub-Agent 才有存在的必要。不能仅仅因为“关注点分离”写在设计文档里听起来不错，就引入 Sub-Agent。

对于上下文量极大的任务，如果 prompt 会撑爆 token 预算，专业 Agent 确实有意义。但通用 Agent 能以更低的运维成本处理 80% 的使用场景。你必须清楚自己正在构建哪一种 Agent，以及为什么要这样构建。

7. 只测试顺利路径的评估

这是最容易带来惨痛教训的一点。

你写了 50 个 eval 用例，Agent 通过了其中 48 个。发布吧。

然后，用户找出了你从没想到过的另外 200 个边缘场景。模型会幻想出一个账户 ID；面对本应回答“我不知道”的问题，它却信心十足地给出答案；它甚至会使用一位客户的数据去回答另一位客户的问题。

好的 eval 不是测试 Agent“能否”正确回答，而是测试它在压力之下“是否真的会”正确回答。

围绕失败模式构建 eval：

当工具返回空结果时，会发生什么？

当两个工具返回的信息互相冲突时，会发生什么？

当用户询问的内容略微超出 Agent 的领域范围时，会发生什么？

当上下文存在歧义时，会发生什么？

eval 套件才是真正的护城河。不是模型，不是 prompt，也不是架构。能够系统性发现并修复失败模式的团队，构建出来的 Agent 会优于那些拥有更花哨框架的团队。

令人不安的真相

你的 Agent 中，大多数复杂性并没有让它变得更聪明，只是让它更难调试、更难评估，也更难修改。

我构建过的最佳 Agent 架构都简单得让人不好意思：一个模型、清晰的 system prompt、命名合理的工具、优质的数据，以及毫不留情的 eval。

除此之外的一切，要么是过早优化，要么是一堂等待你付出高昂代价的课程。

我帮助 B2B SaaS 公司在六周内交付生产级 AI。

不确定哪些该保留、哪些该砍掉？我提供免费的 AI Teardown 服务。我会针对你的 AI 系统录制一段 30～45 分钟的视频，准确指出哪些部分只增加了复杂性，却没有创造价值。不推销，只帮你理清问题。你可以在这里预约。