Ai-Engineering

2023 年 3 月，一个名叫 Toran Bruce Richards 的开发者发布了 AutoGPT，两周内 GitHub Star 突破 10 万。他在 README 里写道：「给 AI 一个目标，它自己规划、自己执行、自己反思。」不需要你画流程图，不需要定义任务依赖——完全自治。

三个月后，Richards 的 GitHub Issues 页面变成了大型翻车现场。一个被反复引用的案例：用户让 AutoGPT「研究人工智能的历史」，Agent 搜索了 10 篇文章，保存，然后又搜索了 8 篇，再保存，然后检查自己保存的文件，然后重新搜索……无限循环，API 费用烧了几十美元，一事无成。AutoGPT 的 GitHub 仓库里记录了超过 200 个类似的 infinite loop issue。

AutoGPT 的失败让行业得出了一个看似正确的结论： Agent 需要预定义的执行图。于是 LangGraph 成了 2026 年最受欢迎的 Agent 框架——62% 的开发者选择了它，正是因为它提供了精细的状态机控制和可预测的执行路径。

但我跟很多在用 LangGraph 的团队聊过，他们私下都在抱怨同一件事： 画图太痛苦了。 每增加一个能力，就要重新设计图的拓扑结构；每遇到一个边界情况，就要加一条边和一个条件分支。开发者的时间，一半花在写 Agent 逻辑，另一半花在维护那张 DAG。

这就引出了一个真正的问题：DAG 是答案吗？还是我们在 AutoGPT 的阴影下过度矫正了？

过去两年，AI 行业经历了一场静悄悄的范式转移。

2023 年，所有人都在讨论「AI 如何理解人类意图」——我们期待模型能读懂模糊的需求、补全缺失的上下文、容忍随意的表达。那时的产品逻辑是 让 AI 适应人。

到了 2026 年，现实给出了不同的答案。在钉钉推进 AI 落地的过程中，我们观察到一个清晰的趋势： 高效使用 AI 的团队，不是那些等待模型更聪明的人，而是那些主动调整自身行为模式去适配 AI 能力边界的人。

这不是妥协，而是杠杆。

2026 年初，“Harness Engineering” 突然成为 AI 工程圈的热词。顶会论文、技术博客、框架文档都在反复强调同一个公式：Agent = Model + Harness。斯坦福 IRIS 实验室的对照实验表明，固定模型仅更换 Harness 架构，任务完成率可产生 6 倍 的性能差距。

但如果我们剥开这层新术语的外衣，会发现一个略显讽刺的事实：Harness Engineering 并不是什么新发明，它只是人类过去 60 年积累的工程纪律，在 LLM 时代的一次强制回归。

从 Dijkstra 对 goto 的批判，到 GoF 的设计模式，再到控制理论与 DevOps，Harness 的每一块基石都早已存在。我们之所以觉得它新，只是因为过去两年，太多开发者试图用裸 LLM 调用跳过工程基础，直到系统在生产环境中失控，才被迫重新捡起这些老规矩。

去年双十一之后，我和两个不同团队的负责人聊了聊。

团队 A 花了六个月打磨一套微服务架构：精致的 API 网关、完善的链路追踪、99.99% 的 SLA 承诺。上线那天，一切完美。

团队 B 用了两个月搭了个「粗糙」的系统：简单的单体应用、基础的日志收集、甚至有些地方用了硬编码。但他们在系统里埋了一个东西 —— 一套基于运行数据自动调优的反馈循环。

六个月后再看，团队 A 的系统依然「完美」，只是业务变了三次方向，每次都要拉齐五个服务重新发版，工程师疲于奔命。团队 B 的系统已经迭代了四十多个版本，配置参数自动优化了三轮，连架构都根据流量模式自动拆分了两个热点模块。

这不是关于谁的技术栈更好的故事。

这是关于 你在构建的是资产还是负债 的故事。

团队里的小王和小李都在用同一个 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 的「加分项」，而是规模化后的「必选项」。

上周，隔壁组的小天在周会上很兴奋：“用 Cursor 一天写了 3000 行代码，这周迭代速度提升了一倍！”

同一周，他的服务触发了 4 次线上告警。

原因不复杂：AI 生成的代码跑通了主流程，但边界条件没覆盖，异常处理有遗漏，依赖服务的超时场景没考虑到。3000 行代码里，有 800 行是"看起来能跑"的代码。

小天不是个例。过去一年，几乎所有团队都经历了同一个曲线：

1. 第一个月：AI 编码工具让产出翻倍，团队欢呼
2. 第二个月：Bug 率上升，线上事故增多，开始还债
3. 第三个月：实际交付速度回到了 AI 之前的水平，甚至更慢

问题出在哪里？

AI 降低了"写代码"的成本，但没有降低"交付可靠产品"的成本。 而后者，才是生产力的真实度量。

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

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

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

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

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

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