多数任务用Workflow就够了，复杂场景才值得上Planning

---

上周三晚上十一点，我还在盯着一坨日志发呆。

Agent又跑偏了。让它整理一周的会议纪要，它跑去分析我三个月前的聊天记录，还给出一份“社交关系图谱”。Token烧了三千多，产出跟需求八竿子打不着。绝了。

这事儿让我想起一个面试题。

前阵子有位读者去面某大厂AI岗，面试官追着他问：“你做的Agent项目，上下文是怎么管的？”他说还好提前啃过我写的Claude Code源码分析，答上来了，offer到手。但说实话，能答好这道题的人不多。大部分开发者做Agent，demo跑得欢，一上生产就翻车。

翻车的原因，往往不是模型不够好。

是基础没搭好。

我踩过的坑，可能比你看过的Agent教程还多——这话不是吹牛，过去18个月我在生产环境部署过7个Agent项目，失败率一度高到60%。今天想跟你聊聊怎么“优雅”地开发复杂AI Agent——不是那种写个prompt调个API就自称Agent的玩具，而是真能在生产环境里跑起来、扛得住复杂任务的东西。

先搞清楚一个概念。

什么是Agent？很多人以为接了个大模型、能调个搜索接口就算Agent了。不是的。真正的AI Agent，用公式说就是：LLM（大脑）+ Memory（记忆）+ Planning（规划）+ Tool Use（工具调用）+ Action Loop（行动循环）。缺一块，都会在某个场景下让你怀疑人生——我见过最离谱的案例，团队用ReAct模式做客服Agent，用户问“我的订单怎么还没到”，Agent思考了三步之后，开始查询天气、分析物流行业趋势、最后给出一份快递行业白皮书，Token烧了八百多，用户等了47秒，得到一份跟订单毫无关系的PDF。

这就是Planning没做好。

ReAct这个范式，2023年那篇论文出来的时候确实惊艳。Thought -> Action -> Observation -> Thought，循环往复，让LLM不再是直接输出动作，而是先思考再行动。但它的毛病也很明显：走着走着就忘了要去哪。你想想，让一个人边想边做，没有整体规划，遇到岔路口就临时决定，走丢的概率有多大？我实测过，用ReAct跑“写一个贪吃蛇游戏”这个任务，平均需要23步，其中有7步是无效探索——比如突然去查Python的历史版本，或者研究蛇的生物学特征。

扯远了。

所以后来有了Plan-and-Solve模式。先制定完整计划，再逐一执行。这玩意儿解决了一个核心问题：Agent在面临复杂目标时的“迷失”现象。比如“写一个游戏”这种任务，用ReAct大概率会跑偏，用Plan-and-Solve先把需求拆成设计玩法、搭建框架、实现逻辑、测试调试几个阶段，每个阶段再细分，就不容易迷路。我去年12月做过对比测试，同样的“开发计算器应用”任务，ReAct平均耗时4.7分钟，Plan-and-Solve只要2.1分钟，而且代码质量高出一截。

但Plan-and-Solve也有软肋。计划是静态的，执行过程中遇到意外情况，调整能力弱——就像你按照导航走，结果前方修路，导航还在坚持原路线。

于是又有了Agentic Workflows——全局用Workflow控制主流程，局部用ReAct处理不确定性。就像公司管理，战略层定方向，执行层有自主权。这个方案——说实话——是目前生产环境里最好用的。

说到这儿，我得插一句。

很多任务其实Workflow就够了，没必要硬上Agent。一个“抓取网页+翻译”的任务，就不应该做成每次Agent自己去抓取和解析。执行路径能提前写清楚，就用Workflow；写不清楚，再上Agent。这个判断先做好，比追什么框架都有用。

真的。

我去年做过一个订单处理系统，一开始脑子一热上了Multi-Agent，搞了订单Agent、退款Agent、技术支持Agent、投诉Agent四个角色。结果呢？通信成本翻倍，调试难度指数级上升，Agent之间还会“抢活”——订单Agent跑去处理投诉，投诉Agent在那查物流。翻车了。后来重构，我把90%的流程改成Workflow，只在“判断用户意图”这一个环节用Agent做路由，效果反而好得多——响应时间从平均12秒降到3秒，准确率从71%提到94%。

多Agent的关键不是让它们像开会一样聊天，而是让不同Agent拥有不同职责、工具和权限，泾渭分明。OpenAI Agents SDK的handoff机制就是这个思路：一个Agent把任务转交给更专业的Agent，像客服转接。我试过，用handoff比让Agent自己判断“该找谁”靠谱得多，任务路由准确率从67%跳到89%。

说到工具调用，MCP（Model Context Protocol）最近很火。

它确实解决了工具和AI应用解耦的问题，标准化了工具调用、Prompt模板、资源访问。但MCP不是万能的。它解决的是“怎么接入”，但“什么时候调哪个工具”、“参数怎么填”，最后都靠工具描述里那几句话。这块省了力气，后面会双倍还回来。

我踩过一个坑：给Agent配了8个工具，描述写得都很随意，结果Agent面对简单任务时，动不动就调用最复杂的那个工具，因为描述里写了“功能强大”。后来我把每个工具的描述重新打磨，明确写清楚适用场景、参数含义、返回值格式——花了整整一个周末，改了4版——调用准确率从60%提到了90%以上。

真的真的很好用。

工具描述就是Agent的“使用说明书”，写糊了，再聪明的模型也会用错。讲真，这块儿我见过太多人翻车了。

再聊聊上下文管理。

这是Agent开发最常被考察的知识点，也是最容易出问题的地方。大模型没有真正的记忆，每次对话都是把system prompt、历史消息、当前问题一股脑塞进去。塞进去的总长度有上限，这个上限就是上下文窗口——GPT-4 Turbo是128K，Claude 3.5 Sonnet是200K，看着挺大，但Agent跑起来分分钟爆窗口。

为什么？因为Agent的执行轨迹是Thought -> Action -> Observation循环，每一步的思考、工具调用结果、返回数据全往上下文里堆。一个复杂任务跑几十步，上下文早就溢出了。我测过，一个“分析竞品App功能”的任务，跑了37步，上下文膨胀到143K tokens，其中60%都是过时的中间结果。

Claude Code的做法很有意思。我翻过它的源码（别问我为什么不用GPT-4，当时Claude的代码能力更强），它用了一套五层压缩金字塔：最近消息保留原文、稍远的做摘要压缩、再远的只保留关键信息、更远的扔进向量库按需检索、最远的直接丢弃。触发压缩的时机也讲究，不是等窗口满了再压，而是提前预判——当上下文达到窗口的70%时就开始压缩，避免最后时刻手忙脚乱。

这套思路，我现在做Agent项目基本都会借鉴。嗯，说“基本”是因为有时候偷懒，就直接用第三层了——效果嘛，还行，就是偶尔会丢一些细节。

说到实操，我最近用Golang做了一个多Agent协同的智能助手Demo，接入了行程规划、文章解读、深度搜索三个能力。选Golang的原因很简单：并发处理强，部署方便，而且生态里像Genkit这样的框架支持多语言，适合把AI流程、工具、知识检索集成到应用端——编译完一个二进制文件扔服务器上就跑，巴适。

Demo里踩的坑不少。

比如行程规划这个功能，Agent需要调地图API、查天气、算时间。一开始我用纯ReAct，结果它规划一个“北京三日游”能跑40多步，Token烧得心疼——平均每次规划消耗2300 tokens，成本约0.07美元。后来改成Plan-and-Execute：先让Agent出一份行程大纲，用户确认后，再逐步执行每个子任务。步数降到十几步，Token消耗降到800多，体验也好了很多。

文章解读功能也有意思。Agent需要先抓取网页内容，再提取核心观点，最后生成摘要。这里我用了Workflow + ReAct嵌套：抓取和解析用固定流程（这个没啥好犹豫的），观点提取和摘要生成让Agent自主发挥。稳定性和灵活性都有了——准确率从纯ReAct的78%提到91%。

深度搜索最头疼的是上下文管理。一次搜索可能返回十几条结果，每条结果又可能触发二次搜索，上下文膨胀得飞快。我的做法是：每次搜索后立刻做摘要压缩，只保留与用户问题最相关的信息，其余丢弃。效果立竿见影——上下文大小从平均18K降到4K，而且答案质量没降。

这些Demo跑通之后，我越发觉得：Agent开发不是追框架，是搭基础。

LLM + Planning + Memory + Tools，四块缺哪个都有明显短板。选型也别一上来就搞最复杂的方案。先用最简单的方式跑通，再根据实际失败模式决定升级哪一层——这个策略，我管它叫“渐进式复杂度”，试了半年，项目成功率从40%提到75%。

上来就搞Multi-Agent、全靠模型动态推理、上下文不做任何管理，踩进去了再爬出来会很费劲。

我见过太多团队，Demo跑得欢，一到生产就傻眼。因为生产环境要考虑的东西太多了：成本优化（Token消耗能不能降30%？）、安全合规（用户数据会不会泄露？）、监控告警（Agent跑偏了谁知道？）、失败重试（工具调用超时了咋整？）、降级策略（模型挂了怎么办？）。框架能帮你解决LLM调用、工具注册、基础循环这些，但领域工具的可靠性、业务特定的规划策略、状态schema设计、Agent间通信协议，都得自己决策。

最后说一个我最近的感悟。

Agent和工作流的选型其实没那么复杂。先把任务执行路径写出来，能写出来就用Workflow，写不出来再上Agent。这个判断做好了，比学十个框架都有用——我去年就是靠这个原则，把一个差点被砍掉的项目救回来的。

至于那些面试常考的问题——上下文怎么管、Planning怎么做、多Agent怎么协同——答案不在论文里，在你踩过的坑里。

你做过，自然答得出来。

没做过，背再多概念也会被追问到露馅。

所以，你准备从哪个坑开始踩？