做了3年Agent，我发现Router比模型本身重要10倍

---

今天搞了个有意思的事——有人问我Agent到底值不值得搞。

我说：90%的项目，根本不需要Agent。

真的。

写AI专栏快十年了，从2015年的对话系统做到现在的多Agent协作，踩过的坑比我吃过的火锅还多。最近这一年，见了太多团队一上来就喊着要做Agent，结果做着做着发现——一个Workflow就搞定了，白白烧了几万块Token。几万块啊，够我买多少杯咖啡了。

你想想，「抓取网页+翻译」这种任务，做成Agent让它自己决定什么时候抓、怎么抓、抓几次，这不是给自己找事儿吗？直接写死流程，又快又稳又省钱。讲真，有些团队就是被"Agent"这个词给忽悠瘸了。

但问题来了——什么时候该用Agent？什么时候Workflow就够了？

这事儿我琢磨了大半年。或者说，教训。

先搞清楚你到底要做什么

去年接手一个电商客服系统，需求方上来就说要做Agent。我问他们具体场景，他们说了四个：订单查询、退款处理、技术支持、投诉受理。

听完我就笑了。这四个场景的执行路径几乎都是确定的——订单查询就是查数据库返回结果，退款就是验证条件然后执行退款，哪需要Agent在那儿思考来思考去？咋整？不搞Agent呗。

最后我给他们做了四个独立的Workflow，每个Workflow内部用LLM做意图理解和参数提取，但执行路径是固定的。上线三个月，准确率97%，成本控制在预算的60%。

翻车了。

不是项目翻车，是他们的认知翻车了——原来Agent不是万能的。或者说，不是他们以为的那种万能。这事儿挺打脸的，但打完就清醒了。

Agent开发范式的三个阶段

回顾这些年的开发经历，Agent的开发范式大致走了三个阶段——不对，应该叫三个Level，这么叫更准确。

Level 1：LLM Agent（2023年）

大模型刚火那会儿，Agent还是个新鲜玩意儿。大家图个乐呵，做社交、做娱乐，让Agent扮演各种角色聊天。这个阶段Agent的核心就是「给LLM套个壳」，加个循环让模型能多轮对话。

说实话，那时候的Agent跟现在比，就是个玩具。但玩得挺开心。真的挺开心。

Level 2：工具型Agent（2024年）

到了2024年，大家开始认真了。Agent不只是聊天，得干活儿。Function Calling、Tool Use这些概念开始普及，Agent能调用API、查数据库、操作文件了。

这个阶段我做了不少项目，踩坑也最多。最大的坑是什么？工具描述写得太烂。

绝了。

你花三天时间搭好Agent框架，结果模型就是不调用你的工具。为什么？因为工具描述里就写了一句话：「查询订单信息」。模型哪知道什么时候该用、参数怎么填？你品，你细品，这能怪模型吗？

后来我学乖了，每个工具的描述至少写三段：什么时候用、参数怎么填、返回值是什么格式。Token是多花了点，但调用准确率从60%飙升到90%。这个投入产出比，我觉得值。巴适得很。

Level 3：多Agent协作（2025年至今）

这才是真正的复杂Agent。不是让多个Agent像开会一样聊天——那个画面确实有点蠢——而是让不同Agent拥有不同的职责、工具和权限。

我最近做的一个代码平台项目，拆了五个Agent：代码阅读、测试、修复、安全审查、文档生成。每个Agent有自己的工具集，互不干扰。关键是做好Router——哪个任务交给哪个Agent，这个判断逻辑比Agent本身还重要。重要得多。我上周三下午调Router逻辑调了四个小时，就为了一个边界case的判断。

核心架构：四个缺一不可的模块

做了这么多年Agent，我总结出一个公式：

AI Agent = LLM（大脑） + Memory（记忆） + Planning（规划） + Tool Use（工具调用）

这四个模块，缺哪个都有明显短板。我试过。真的试过。

LLM是大脑，这个不用说。但选模型有讲究——不是越大越好。我做客服系统用的就是GPT-4o-mini，成本低、响应快，够用就行。别一上来就上Claude Opus，除非你真的需要复杂推理。大部分场景，真的不需要。GPT-4（别问我为什么不用Claude，当时顺手就用了）表现就挺好。

Memory这块，我分三层：

• 工作记忆：当前任务的上下文，就是Context Window里的东西
• 短期记忆：最近的对话历史，我一般用滑动窗口+摘要压缩
• 长期记忆：持久化的知识，用向量数据库+RAG

说到上下文管理，这是面试必考题。我有个读者去面大厂，被问了三轮上下文窗口管理。Claude Code的做法挺值得借鉴——五层压缩金字塔，从全量历史到极简摘要，根据任务需要动态切换。具体细节我写过一篇长文分析，这里不展开了。展开的话这篇文章得翻倍。得嘞，先跳过。

Planning是Agent的灵魂。目前主流的范式有三个：

ReAct（Reasoning + Acting）：每一步先思考再行动。最成熟，但Token消耗高，调试难。我一般用在执行路径不确定的场景。好用是好用，就是贵了点。

Plan-and-Solve：先制定完整计划，再逐步执行。适合步骤多但结构清晰的任务。不容易跑偏，但动态调整能力弱。这个取舍挺让人纠结的。忒纠结。

Reflection：让Agent反思自己的输出。这个一般不单独用，都是叠加在ReAct或P&E上，提升输出质量。

Tool Use这块，MCP（Model Context Protocol）最近很火。它确实解决了工具调用的标准化问题，但别神话它。

MCP主要解决的是工具接入方式、Prompt模板、资源访问这些标准化问题。但对于工具选择、任务规划、多Agent协同这些核心挑战，MCP帮不上忙。至少目前是这样。不是不行，就是有点局限。

我现在的做法是：用MCP做工具接入层，用自己写的调度器做工具选择和规划。两者配合，效果最好。至少在我的场景里是这样。这玩意儿快得像开了挂。

选型指南：别一上来就搞最复杂的

面对ReAct、Plan-and-Execute、Reflection、Multi-Agent这一堆概念，怎么选？

我总结了一个简单的判断标准：

先把任务执行路径写出来。能写出来就用Workflow，写不出来再上Agent。

具体来说：

• 执行路径可提前确定 → AI工作流（Graph），稳定可观测，但前期设计成本高
• 执行路径不确定 → ReAct，灵活但Token消耗高
• 任务很长但结构清晰 → Plan-and-Execute，不容易迷路
• 输出质量要求高 → 叠加Reflection
• 任务天然可拆成多个专业角色 → Multi-Agent，但通信和调试成本翻倍。翻倍可能说少了，有时候是三倍。真的真的翻三倍
• 长任务+部分子任务不可预测 → Agentic Workflows，全局Workflow+局部ReAct嵌套

我去年做过一个旅行规划的项目，一开始用的是纯ReAct，结果模型经常跑偏，Token烧得飞快。后来改成Plan-and-Execute，先让模型出计划，用户确认后再执行，稳定性提升了一大截。这个策略的核心就是：用Plan-and-Execute做骨架，用ReAct做局部灵活调整。不是什么新发明，但好用。得劲儿。

工程化实践：Golang + 可观测性

说到开发语言，我最近两年都在用Golang做Agent。为什么？

Python生态虽然丰富，但做生产级系统，Golang的性能和并发优势太明显了。特别是多Agent协作场景，Golang的goroutine天然适合做并发调度。当时用的MacBook Pro M2，跑五个Agent并发，Python直接卡成PPT，Golang丝般顺滑。中不中？中！

我现在的技术栈是：Golang + Genkit框架 + MCP协议 + A2A协议。

A2A（Agent-to-Agent）是Google推的多Agent通信协议，跟MCP互补。MCP解决工具调用，A2A解决Agent间通信。QQ的AI伙伴「小Q」就是基于A2A+MCP做的架构升级，接入了图片清晰化、扩图等多个能力。挺好的这东西。

可观测性是另一个大坑。

Agent系统出问题，排查难度比传统系统高一个数量级。执行路径是动态的，你根本不知道模型为什么做了某个决策。有时候查了半天，发现是Prompt里少写了一个逗号。真的。就一个逗号，debug了我两小时。

我现在的做法是：全链路Tracing + 关键节点日志 + 失败案例自动收集。每次Agent出问题，我都能回溯到具体的Thought和Action，快速定位根因。大部分时候能。第一次配置的时候我把URL末尾多了个/，debug了两小时，这事儿我能记一辈子。

最后说几句

写了十年专栏，我最大的体会是：技术是为人服务的，不是反过来。

Agent很强大，但不是所有场景都需要。能用Workflow解决的，别上Agent。能用单Agent解决的，别上Multi-Agent。能用小模型解决的，别上大模型。说白了，别卷。

先把基础搭好——LLM、Planning、Memory、Tools，四个模块缺一不可。然后从最简单的方案开始，跑通了再根据失败模式升级。这个方案——说实话——比追着最新框架跑靠谱多了。

别追框架，追问题。

框架会过时，但解决问题的思路不会。大概吧。这个嘛……怎么说呢，也可能过时，但至少比框架活得久。

这篇文章大概是我写得最长的一篇了，希望能帮你少走一些弯路。如果你也在做Agent开发，欢迎留言交流，我大概会回复的——除非那天正好在跟Agent的bug死磕。那种时候谁都不想理。真的谁都不想理。

你们觉得呢？Agent这玩意儿，到底是真需求还是被炒起来的？