Llm-Agent

上周和一位创业者吃饭，他刚帮一家大型企业做完知识图谱项目的评估。结论让人倒吸一口凉气：要达到替代中级岗位能力的水平，算上数据采集、清洗、标注、图谱构建和持续维护，预算需要一个亿。

企业听完直接搁置了。

这不是个例。过去三年，我见过不下十个类似的项目——企业想做知识库，供应商画了一个「知识图谱+智能问答」的大饼，然后企业发现投入产出比根本算不过账。

但今年情况变了。模型能力的跃迁正在催生一个新范式：不再靠人工标注堆数据，而是让 LLM 做编排，结合企业搜索，人做优化调整和确认。

知识整理的起点也不再是宏大的「企业知识图谱」，而是每个人手边的 Journal——每日工作日记。通过钉钉这样的组织连接工具，个人知识可以自然地流转、沉淀为企业知识。

团队里的小王和小李都在用同一个 AI Agent 平台。

小王输入：「帮我总结一下今天群里的讨论。」

Agent 调用了 fast/small 模型做意图识别，然后用 medium 模型读取了 200 条消息，生成了摘要。耗时 3 秒，花费 0.02 元。

小李输入了完全相同的指令。

Agent 却调用了 large/reasoning 模型，不仅做了摘要，还自动关联了小李上周的项目文档，识别出了三个待办事项，并推送到了他的日历。耗时 12 秒，花费 0.15 元。

同样的输入，完全不同的执行路径。

这不是 bug，而是一个成熟的 Agent 系统应该具备的能力——根据用户画像、历史行为、任务上下文，动态决策每一步该用什么模型、什么工具、注入多少上下文、以什么并发度执行。

当你的 Agent 只有 100 个用户时，这些问题还不明显。你可以手动调几个规则，给 VIP 用户分配更好的模型，给普通用户限流。靠人肉运维，系统也能跑。

但当用户量从 100 涨到 10 万、100 万，当模型供应商从 1 家变成 10 家，当工具调用从几个 API 扩展到上百个——靠人写规则来调度，系统会直接崩溃。

不是因为规则写不出来，而是因为规则的组合空间是指数级的：

• 7 种任务类型 × 5 个复杂度等级 × 10 个模型 × 4 种用户画像 × 3 种上下文策略 = 4,200 种路由组合
• 这还只是单节点决策。如果任务被分解为 3-5 个子节点，每个节点独立路由，组合数直接爆炸到 百万级

没有人能手动维护百万级的路由规则表。

大多数 Agent 框架把执行路径写死在代码里：先调用 A 模型，再调用 B 工具，最后返回结果。这在 demo 阶段没问题，但一旦面向规模化用户，就会暴露三个致命问题：

1. 成本失控——所有用户都用最强模型，简单任务也在烧钱，规模化后月账单直接六位数
2. 体验一刀切——新手和专家拿到相同的结果，没有人觉得「懂我」，留存率上不去
3. 无法进化——系统上线后不会从用户反馈中学习，规则越写越多，越用越僵化

这篇文章，我们来拆解如何构建一个动态路由决策系统（Dynamic Routing Decision System, DRDS）——一套端到端的自进化引擎，让 Agent 的执行路径真正做到千人千面，并且在规模化下持续学习、自动优化。

核心观点：自进化不是 Agent 的「加分项」，而是规模化后的「必选项」。

去年年底，我做了一个实验：把过去十年写的 190 多篇博客、Obsidian 里的读书笔记、还有悟空 Agent 的实践记录，全部扔给 Hermes Agent，让它按照 Karpathy 的 LLM Wiki 模式自动整理。

三天后，我打开 Obsidian 的 Graph View，看到了一个由 50 多个节点互相连接的知识网络 — 不是文件归档，而是一个真正的知识图谱。Agent 自动提取了实体和概念，建立了双向链接，甚至发现了我自己都没意识到的关联：[[compression-as-intelligence]] 和 [[agent-memory]] 之间有一条隐含的逻辑链，我自己写了三年都没发现。

那一刻我意识到：个人知识管理的瓶颈不是工具，而是"碎片到结构"的转换成本。 这篇文章，我把整个系统的架构、自动化流程和实际用法完整拆解出来。

上周三晚上 11 点，老王给我发消息：他们的桌面 Agent 上线刚满 30 天，DAU 爬到 8000，团队 4 个人。他翻了一周用户行为日志，发现一个反直觉的事实——用过 3 次以上的用户里，62% 只把它当"自然语言版的快捷启动器"用，真正让它做跨应用编排的不到 13%。但他们的技术栈正按"复杂编排"在搭：每个 query 直接扔给 GPT-4o 做 function calling，P50 延迟 1.6 秒，P99 干到 3.8 秒。

老王问：“我看了你之前那个四层意图漏斗，要不要现在就全套上？团队就 4 个人，老板说三个月内要把日活做到 5 万，怕 over-engineering。”

我的答案：要上，但不是一次上四层。1 个月的 Agent 团队最缺的不是模型层数，是能让你做对决策的数据。

上周团队里的某同事给他的 AI Agent 加了一个"帮我总结这个网页"的功能。用户发一个 URL，Agent 自动打开、提取内容、生成摘要。听起来很简单对吧？

结果上线第一天就翻车了。

一个用户发了一个 GitHub 仓库链接，Agent 用浏览器沙箱打开了仓库首页，截取了 README 的前几屏，然后用一个 7B 的轻量模型生成了摘要——完全忽略了仓库里真正的核心代码和 issue 讨论。用户等了 40 秒，得到了一段废话。

同一个功能，另一个用户发了一个新闻网站链接，这次 Agent 反而用了最强的推理模型去处理——一个纯文本提取任务，花了不必要的 token 费用，还因为推理模型的"过度思考"把简单的新闻摘要写成了一篇分析报告。

某同事跑来找我：“模型能力明明够了，为什么用户体验这么差？”

我说：“你的问题不是模型不行，是你没有给任务找到合适的模型和执行环境。你缺的是一个推荐系统。”