智能体这个词在过去一年被用得太泛了。打开任何一个技术社区满屏都是三分钟搭建你的第一个Agent零代码智能体平台横评但真正把智能体当系统工程来做的人并不多。Anthropic 前阵子发了一篇关于构建有效智能体的架构笔记在圈子里传得很广我前后读了三遍又对着自己手头两个落地项目做了验证发现里面很多判断跟市面上主流的智能体LLM工具调用循环的粗暴理解完全不是一回事。这篇东西我想把那份笔记的核心逻辑拆开讲清楚顺带补上我自己在工程实践里踩过的坑尤其是那些文档里不会写、但一上手就会撞上的问题。如果你正在做智能体开发或者团队里有人天天喊着要上Agent但说不清楚到底要解决什么问题这篇内容应该能帮你把思路理一遍。我不会给你一个万能框架因为那东西不存在但我会把什么样的任务值得用智能体工作流和智能体的边界在哪怎么设计工具接口才不会被模型玩坏这几个真问题讲透。1. 先搞清楚你的任务到底该不该用智能体这是 Anthropic 那篇笔记开篇就在强调的事情也是我觉得最容易被跳过的一步。大部分人拿到需求的第一反应是这个能不能用Agent做而不是这个任务的结构到底适不适合Agent。这两个问题的答案经常是相反的。1.1 工作流和智能体的本质区别先把概念理清楚。所谓工作流Workflow指的是通过预定义的代码路径来编排LLM和工具路径是写死的模型只在特定节点做特定判断。而**智能体Agent**是让LLM动态决定自己的执行路径自己决定调什么工具、调几次、什么时候停。这个区别听起来很学术但落到工程上就是一句话工作流是你控制流程智能体是模型控制流程。Anthropic 的笔记里给了一个很实用的判断标准——看任务的可预测性。如果一个任务的步骤基本固定只是每步需要一点语言理解能力那它就是工作流的活。比如简历筛选流程就是解析简历→提取关键字段→对照JD打分→生成评语这个链路是确定的你完全可以用代码把它串起来中间该调LLM的地方调LLM。这种场景硬上智能体只会让系统变得又慢又不稳定。反过来如果任务需要根据中间结果动态决定下一步做什么而且步骤数量事先说不准那才轮到智能体上场。比如帮我调研一下竞品X最近三个月的定价策略变化这个任务你没法预先写死路径——你可能要先搜新闻发现某条新闻提到了一次调价然后去官网抓历史价格页发现页面结构变了又得换个数据源。这种走一步看一步的任务才是智能体的主场。我自己的经验是80%号称需要智能体的场景其实一个设计良好的工作流就够了。剩下20%里又有一半可以通过工作流为主局部智能体的混合模式解决。真正需要端到端自主智能体的场景比大家想象的要少得多。1.2 一个反直觉的结论智能体不是越自主越好市面上有一种论调觉得智能体越自主越高级能自己规划、自己反思、自己纠错才叫真智能体。Anthropic 的笔记对这个观点是持保留态度的我完全同意。自主性带来的是不确定性和调试难度。一个完全自主的智能体你很难预测它在某个输入下会走什么路径出了问题也很难复现。我在一个客服场景里试过让智能体完全自主决定回复策略结果它有时候会自作主张地承诺一些公司政策里没有的补偿方案这种问题在测试阶段很难穷举出来。更务实的做法是在关键节点加约束。比如规定智能体在涉及退款、赔偿这类敏感操作时必须先走一个固定的确认流程不能自主决定。这就是所谓的有边界的自主——在安全范围内给它自由在风险点上收回来。提示判断一个任务该不该用智能体先问自己三个问题——步骤是否可预测步骤数量是否固定出错成本是否可控三个都是否才考虑智能体否则优先工作流。1.3 从成本角度看这件事还有一个很多人忽略的维度成本。智能体的每一次自主决策都意味着一次甚至多次LLM调用token消耗是工作流的几倍甚至几十倍。我做过一个对比测试同样一个信息提取任务工作流方案平均消耗1200个token智能体方案平均消耗8500个token差了7倍。这不只是钱的问题还有延迟。智能体多轮决策带来的响应时间在交互式场景里是致命的。用户问一个问题等30秒体验直接崩掉。所以我的建议是能用工作流解决的绝不上智能体能用简单智能体解决的绝不上复杂智能体。工程上追求的是够用且可靠不是看起来最先进。2. 工具设计智能体能不能干活八成看这里如果确定要用智能体了接下来最关键的不是选哪个模型而是怎么设计工具接口。Anthropic 的笔记里花了很大篇幅讲这个因为这是决定智能体成败的地方。我见过太多项目模型选的是最好的prompt 也调得很用心但工具设计得一塌糊涂最后智能体表现得像个智障。2.1 工具描述是给模型看的不是给人看的这是第一个认知转变。很多人写工具描述的时候是按照给人写API文档的思路来的写得很简洁觉得模型应该能理解。但模型不是人它没有常识补全能力你写得含糊它就真的不知道该怎么用。Anthropic 的建议是工具描述要写得像给一个刚入职、什么都不懂的新人看的操作手册。要包含这个工具是干什么的、什么时候该用、什么时候不该用、输入参数的具体含义和格式、返回值的结构、可能的错误情况。举个例子一个查询订单的工具差的描述是查询订单信息好的描述是根据订单号查询订单的详细状态包括支付状态、物流状态、预计送达时间。当用户询问订单进度、物流信息或需要确认订单是否已支付时使用此工具。输入必须是完整的订单号格式为18位数字不接受部分订单号或用户名查询。这个差别在实际运行中非常明显。我做过A/B测试用详细描述的工具智能体调用正确率从62%提升到了89%。2.2 工具粒度太粗和太细都是坑工具设计有个经典的粒度问题。工具太粗一个工具干太多事模型很难用对工具太细工具数量爆炸模型选择困难。我的经验法则是一个工具对应一个明确的意图。比如发送邮件这个动作不要设计成send_email(to, subject, body, cc, bcc, attachments, priority, ...)这样一个大而全的工具而是拆成发送简单通知邮件和发送带附件的正式邮件两个工具每个工具的参数都精简到必需。但也不能拆得太细。我见过有人把读取文件拆成打开文件读取第一行读取下一行关闭文件四个工具这就过度了模型得调四次才能读完一个文件效率极低还容易出错。一个实用的判断标准是如果一个工具需要模型连续调用三次以上才能完成一个用户能理解的原子操作那这个粒度就太细了如果一个工具的参数超过7个或者返回值需要模型做复杂解析才能用那这个粒度就太粗了。2.3 错误处理让工具自己说清楚哪里错了工具调用失败是常态关键是怎么让模型知道失败了、为什么失败、该怎么补救。很多工具出错就返回一个Error或者抛个异常模型拿到这个信息完全不知道下一步该干嘛。好的做法是返回结构化的错误信息包含错误类型、错误原因、建议的补救措施。比如{ status: error, error_type: invalid_parameter, message: 订单号格式不正确应为18位数字, received: 12345, suggestion: 请向用户确认完整的订单号或使用订单查询工具通过手机号查找 }这样模型拿到错误后能自己判断是该重试、该换个工具、还是该向用户追问。我在实际项目里加上结构化错误返回后智能体的自主纠错成功率提升了一倍多。注意工具的错误信息里不要暴露内部实现细节比如数据库表名、堆栈信息这些既没用又可能带来安全风险。2.4 工具的数量控制Anthropic 的笔记里提到一个经验值同时提供给智能体的工具数量最好控制在10-20个之间。太少不够用太多模型会挑花眼。如果业务确实需要很多工具解决方案是分层。先给智能体一组元工具比如查询类工具操作类工具分析类工具让它先选类别再在类别里选具体工具。或者用动态工具加载根据当前上下文只把相关的工具塞进prompt。我在一个电商客服项目里工具总数有40多个直接全塞进去模型经常选错。后来改成按对话阶段动态加载——售前阶段只加载商品查询类工具售后阶段只加载订单和退款类工具准确率立刻上来了。3. 记忆与上下文智能体的工作台怎么摆智能体跟普通LLM应用最大的区别之一就是它需要维护一个跨多轮、跨多步骤的上下文。这个上下文怎么组织直接决定了智能体能不能记住自己干过什么、干到哪了。3.1 上下文不是越长越好很多人有个误区觉得上下文窗口越大越好把所有历史都塞进去。但实际测试下来上下文越长模型对关键信息的注意力越分散而且成本和延迟都上去了。Anthropic 笔记里推荐的做法是分层记忆把上下文分成几个层次每层有不同的保留策略。工作记忆当前任务相关的即时信息完整保留任务记忆当前任务的进展摘要压缩保留长期记忆跨任务的知识和经验按需检索我自己的实现是工作记忆保留最近5-10轮的完整对话任务记忆用LLM定期把前面的内容压缩成一段摘要长期记忆存在向量库里按相关性检索。这样既保证了关键信息不丢又控制了上下文长度。3.2 摘要压缩的时机和方式摘要压缩什么时候做是个技术活。做太频繁信息损失大做太少上下文又爆了。我的经验是按token数触发而不是按轮数。设定一个阈值比如上下文用到窗口的60%时触发压缩把最早的那部分内容压缩成摘要。这样能自适应不同长度的对话。压缩的方式也有讲究。不要简单地让LLM总结一下而是给它明确的指令保留哪些信息任务目标、已完成步骤、关键结论、待办事项丢弃哪些信息寒暄、重复确认、中间过程的细节。我用的prompt大概是这样请将以下对话历史压缩成一段简洁的进展摘要用于后续任务继续执行。 必须保留任务目标、已完成的步骤及结果、当前状态、待解决的问题、重要的用户偏好或约束。 可以省略问候语、重复的确认、已经解决的中间问题、工具调用的原始返回只保留结论。 输出格式一段不超过300字的自然语言摘要。3.3 上下文超长时的降级策略即使做了压缩有些任务就是会超长比如处理一个几百页的文档。这时候需要有降级策略。我常用的几种分块处理把大任务拆成小任务每个小任务独立处理最后汇总。比如分析一份长报告先按章节拆开每章单独分析最后合并结论。外部存储检索把中间结果存到外部需要时再检索回来。比如处理过程中产生的中间数据不放在上下文里而是存到文件或数据库需要时用工具读回来。人工介入点在上下文快满的时候主动暂停让用户确认或提供额外信息然后开一个新的上下文继续。这个策略在长流程任务里特别有用。4. 从Demo到生产那些只有上线才会暴露的问题前面讲的都是设计层面的东西这一节我想聊聊落地。Demo跑通和生产可用之间隔着一条巨大的鸿沟。我踩过的坑基本都在这一段。4.1 循环失控智能体停不下来这是最常见的问题。智能体陷入一个循环反复调用同一个工具或者反复在几个状态之间跳来跳去就是不停。原因通常有几个工具返回的信息让模型误以为任务没完成模型对完成的判断标准不清晰错误处理逻辑让模型一直在重试。解决方案是设置硬性约束。我一般会加三层保护第一层是最大步数限制比如最多执行20步到了就强制停止并返回当前结果。第二层是重复检测如果连续三次调用同一个工具且参数相同就中断并报错。第三层是超时控制整个任务超过设定时间就终止。这些约束看起来简单但能避免90%的失控情况。关键是中断之后要有合理的降级处理不能直接给用户一个错误而是返回任务未完成已完成的部分是XXX建议XXX。4.2 工具调用的参数幻觉模型会编造工具参数这是很常见的问题。比如工具要求传订单号模型可能编一个看起来像订单号的字符串出来。这个问题的根源往往是上下文里缺少真实参数。模型不知道真实订单号又必须填这个参数就只能编。解决办法有两个方向。一是在prompt里明确告诉模型如果缺少必要参数应该先向用户询问而不是猜测。二是在工具层面做校验参数格式不对直接返回错误让模型重新处理。我在实际项目里还加了一个技巧把已知的真实参数显式地放在上下文里比如当前用户的订单号是XXX这样模型就不用猜了。4.3 多轮对话中的状态丢失智能体在多轮对话里经常忘记之前确认过的信息。比如用户第一轮说了要查北京到上海的航班第三轮智能体又问请问您要查哪条航线。这个问题一部分是上下文管理的问题一部分是状态没有显式化。我的做法是维护一个结构化的状态对象把对话中确认的关键信息都存进去每轮都把这个状态注入到上下文里。这样即使对话历史被压缩了关键状态也不会丢。状态对象大概长这样{ task: 查询航班, confirmed_params: { departure: 北京, arrival: 上海, date: 2024-06-15 }, pending_params: [舱位偏好], completed_steps: [确认出发地, 确认目的地, 确认日期] }4.4 评估怎么知道你的智能体到底行不行最后一个大坑是评估。智能体的输出是不确定的同一个输入可能走出不同的路径传统的单元测试根本不够用。我的做法是建一个场景测试集覆盖典型场景、边界场景、异常场景。每个场景定义好输入、期望的关键行为不要求完全一致的输出、以及不能出现的行为。然后用自动化脚本批量跑人工抽查结果。关键指标我一般看这几个指标含义目标值任务完成率成功完成任务的对话占比85%平均步数完成任务的平均工具调用次数越少越好工具调用准确率工具选择正确的比例90%循环发生率出现循环的对话占比2%平均响应时间从用户输入到最终回复的时间15秒这些指标不是一次性能达标的需要持续迭代。我一般每周跑一次全量测试看指标变化定位回归问题。5. 几个真实场景的架构选择理论讲完了我想用几个具体场景说明一下怎么选架构。这些都是我实际做过或深度参与过的项目。5.1 客服工单分类与路由这个场景看起来很适合智能体但我的选择是纯工作流。流程是固定的接收工单→提取关键信息→分类→路由到对应处理组。每一步都是确定性的中间用LLM做信息提取和分类判断就够了。上智能体只会增加不确定性和成本。5.2 竞品情报监控这个场景我用了工作流局部智能体的混合模式。整体流程是工作流定时触发→确定监控目标→抓取数据→生成报告。但抓取数据这一步用了智能体因为不同来源的页面结构不一样需要智能体动态决定用什么方式抓、抓哪些字段。5.3 复杂研究助手这个场景是端到端智能体。用户给一个研究问题智能体需要自己决定查什么资料、怎么查、查到之后怎么分析、发现信息不足时怎么补充查询。这种开放式任务没有固定路径只能靠智能体自主决策。这三个场景的对比很能说明问题任务越开放、路径越不确定越需要智能体任务越固定、步骤越明确越应该用工作流。6. 一些零散但重要的经验最后分享几个我在实践中总结的、不太成体系但很有用的点。Prompt 里的不要做什么比要做什么更重要。模型很容易过度发挥明确告诉它哪些事不能做比告诉它要做什么更能约束行为。比如不要编造用户没有提供的信息不要在未确认的情况下执行写操作。给智能体一个思考的空间。在让它调用工具之前先让它输出一段简短的推理说明为什么要调这个工具、期望得到什么结果。这个推理过程不仅能让决策更准确也方便你调试。日志要记全。智能体的每一步决策、每次工具调用、每个中间结果都要记下来。出问题的时候这些日志是唯一的线索。我一般会把完整的对话轨迹存下来包括模型的原始输出。版本管理要严格。Prompt、工具定义、模型版本任何一个变了都可能影响智能体行为。我见过因为prompt里改了一个标点导致行为变化的案例。所有这些东西都要版本化每次变更都要跑回归测试。别追求一次做完美。智能体系统是迭代出来的先跑通核心流程再逐步优化边界情况。我第一个上线的智能体版本工具只有5个prompt也很粗糙但解决了80%的常见场景。后面根据实际badcase慢慢加工具、调prompt才逐渐完善。这套东西说到底核心就一句话把智能体当软件工程来做而不是当魔法来拜。它有自己的适用边界有需要精心设计的接口有必须处理的异常情况。Anthropic 那份笔记的价值就在于它把这些工程问题讲清楚了而不是又给你画一个通用人工智能的大饼。
