AI Agent从概念到落地：最小架构、安全驾驭与成本控制指南

最近一段时间各大技术社区里“AI Agent”几乎成了流量密码任何人都能搭出一个听起来很酷的演示问它一句话它能自己打开网页、查资料、算数据最后给你一份整理好的答案。但是等我自己动手把这个概念搬进真实业务之后才发现“演示”和“好用”之间隔着一条巨大的河。这篇文章就是我把 AI Agent 从概念到落地走完一遍之后提炼出来的“驾驭指南”主要聊四件事什么才算 Agent、最小可用结构怎么搭、怎么让它不乱跑、以及上了线之后如何控制成本和排查故障。如果你是一个正在尝试把 Agent 接进产品、又要对效果负责的开发者或者刚接触这个方向想少走弯路的工程师应该会很有用。1. AI Agent 究竟是什么先把“能聊天”和“能干活”分开1.1 我见过最多的误解Agent 等于 Chatbot过去两年我参与过不少技术评审会几乎每一次都会遇到有人把 Agent 和 Chatbot 混为一谈。很多人觉得只要接了大模型接口能连续对话、能理解上下文就已经是 Agent 了。这个误解的代价很高团队按 Chatbot 的架构设计了产品等真正要让它处理业务时才发现模型只会“说”不会“做”于是又回头补工具调用、任务编排、状态管理等于把系统重做一遍。Chatbot 的核心是“生成回复”它的终点是文字。Agent 的核心是“完成任务”它的终点是行动和结果。举个例子客户在售后页面问“我的订单到哪了”Chatbot 会生成一段话“请您提供订单号我来帮您查询。”而 Agent 应该能做到自己去订单系统查到状态发现物流已经两天没更新后主动触发人工介入并把处理进度同步给客户。两者的差别不在“说话水平”而在“有没有对外部世界产生作用”。判断一个系统是不是 Agent我习惯问三个问题它有没有明确的任务目标它能不能把目标拆解成若干步骤它有没有调用外部工具的通道三个都满足才算真正入了门。1.2 Agent 的三大特征目标、规划、行动先看第一个特征目标。Agent 不是被动地等待用户一句一句指挥而是接收一个相对模糊的需求后自己定义一个可执行的目标。比如用户说“帮我准备下周的项目周报”它需要把“准备周报”拆成收集数据、整理进展、格式化输出等多个子目标。第二个特征是规划。规划不是简单地把一句话翻译成两步操作而是基于当前信息决定“先做什么、后做什么、做不了时怎么办”。我给新人讲这个概念时经常用一个类比Chatbot 就像超市货架前的导购员你问什么他答什么Agent 更像一个拿着购物清单的采购员进了超市自己找货架、自己挑商品、自己结账回来还会跟你对一遍账单。导购员能不能干活能但他的工作边界是“回答”采购员的边界是“完成采购这个目标”。第三个特征是行动。这里的行动不只是“输出一段文本”而是调用真实工具产生可验证的结果查询数据库、调用业务接口、发送通知、修改文件。没有行动能力的智能体无论推理得多漂亮都只是一个增强版聊天程序。我见过不少团队在规划阶段投入大量精力写思维链却迟迟不肯接第一个工具接口最后演示的时候只能靠口头模拟工具结果这种 Demo 永远走不到生产环境。1.3 闭环反馈Agent 能不能自我修正还有一点容易被忽略却是 Agent 和普通多步调用的分水岭闭环反馈。所谓闭环就是 Agent 执行完一个动作后能观察到这个动作带来的结果再根据结果决定下一步行动。完整的 Agent 循环通常长这样接收输入感知→ 交给模型推理思考→ 选择并调用工具行动→ 把工具返回值重新喂给模型观察→ 继续推理直到输出最终答案。关键就在最后一步“观察”。如果工具返回的结果和预期不符Agent 应该有能力调整策略、换个工具重试、或者如实告诉用户“这条路径走不通”。我见过一个反面案例某团队做了一个文档整理 Agent它会按标题批量重命名文件。第一次测试时工具返回的路径包含特殊字符代码直接抛异常Agent 却把异常信息原样当成“成功执行”的结果输出给用户。问题就出在这个团队没有实现观察环节工具调完就把消息丢给模型模型看到一段报错文本不知道这是错误还以为任务已经完成。所以判断 Agent 是否合格就去看看它的工具执行结果有没有被妥善加工并送回给模型而不是被简单丢弃。2. 搭一个最小可用 Agent核心链路与骨架代码2.1 先划清任务边界很多人一上来就想做一个“什么都懂的全能助理”这是失败最快的开局。我不建议这么做原因很简单Agent 不是搜索引擎也不是自动驾驶它需要在“什么能碰、什么不能碰、输出长什么样”这几件事上有明确边界。以我自己的经验动手前先花半小时回答下面几个问题能省下后面几天的返工。第一输入边界。用户给 Agent 的输入是自由文本、结构化表单还是某个系统导出的文件如果是自由文本要不要先做意图识别第二输出边界。输出的结果是自然语言回复、JSON 数据、还是直接执行业务动作第三工具边界。Agent 能调用哪些系统不能调用哪些系统如果允许它发邮件、改库存、删文件必须设置审批点。第四失败边界。工具出错之后Agent 是自动重试、换一条路还是停下来问人我把这些边界写进第一版 Prompt 里效果立竿见影。曾经有一版 Agent 在没有明确“不得删除”约束时用户一句“清理测试数据”它把几张关联表的数据一起清了。后来所有 Agent 的系统提示词里都固定出现一行“只有用户明确要求且你具有对应权限时才能执行删除类操作。”2.2 三个基础部件最小可用的 Agent 只需要三个部件大模型、记忆、工具集。大模型承担的是“大脑”功能理解用户意图、生成任务规划、决定调用哪个工具、把工具结果组织成最终答案。目前的主流做法是让模型以“函数调用”或“工具调用”的方式输出结构化指令再由代码去执行对应函数。这个设计比让模型直接生成代码再执行要安全得多因为工具列表、参数结构、执行权限都被收拢在可控范围内。记忆部件负责保存两类信息一类是当前任务内的对话历史另一类是跨任务的业务事实。最小版本只需要第一类也就是把用户消息、模型回复、工具返回值按顺序存进一个消息列表每一轮都整体传给模型。不需要一上来就上向量数据库把简单事情先做扎实。工具集是 Agent 能对外部世界产生影响的关键。最小工具集建议控制在五个以内每个工具只做一件事。工具描述要写得像给新人看的工作说明什么时候用、需要哪些参数、返回值是什么结构。我见过太多团队把工具描述写得含糊模型判断不了该用哪个工具最后出现各种奇怪调用。2.3 能跑起来的最小骨架下面这个骨架是我在多个项目里反复用过的简化版不依赖任何特定框架核心就是工具注册、消息循环、模型调用三件事。模型接口部分我做了抽象实际接入任意大模型服务时替换成对应的请求方式即可。import json from typing import Any, Callable, Optional # ---------- 工具注册表 ---------- TOOLS: dict[str, dict[str, Any]] {} def register_tool(name: str, description: str, parameters: dict): def decorator(func: Callable): TOOLS[name] { func: func, description: description, parameters: parameters, } return func return decorator register_tool( search_order, 按订单号查询订单状态输入订单号返回 JSON 字符串, { type: object, properties: {order_id: {type: string}}, required: [order_id], }, ) def search_order(order_id: str) - str: # 这里对接你自己的业务系统 return json.dumps({order_id: order_id, status: shipped, eta: 2025-04-02}) # ---------- Agent 主循环 ---------- class MinimalAgent: def __init__(self, model_client: Any, max_steps: int 8): self.model model_client self.max_steps max_steps self.tool_schemas [ { name: name, description: info[description], parameters: info[parameters], } for name, info in TOOLS.items() ] def run(self, user_request: str, context: Optional[list[dict]] None) - str: messages [ {role: system, content: 你是任务执行助手请根据用户需求调用可用工具必要时可多次调用。}, {role: user, content: user_request}, ] if context: messages context messages for _ in range(self.max_steps): resp self.model.chat( messagesmessages, toolsself.tool_schemas, tool_choiceauto, ) msg resp[message] messages.append({role: assistant, content: msg.get(content, )}) tool_calls msg.get(tool_calls) # 没有工具调用认为已经完成 if not tool_calls: return msg.get(content, ) # 逐个执行模型发起的工具调用 for tc in tool_calls: name tc[function][name] arguments json.loads(tc[function][arguments]) messages.append({ role: tool, tool_call_id: tc[id], content: self._execute_tool(name, arguments), }) return 已达最大步骤限制请补充信息或等待人工介入。 def _execute_tool(self, name: str, arguments: dict) - str: if name not in TOOLS: return json.dumps({error: funknown tool: {name}}, ensure_asciiFalse) try: result TOOLS[name][func](**arguments) return str(result) except Exception as exc: # 关键把异常结构化返回给模型而不是直接中断 return json.dumps({error: str(exc)}, ensure_asciiFalse)这段代码最核心的地方有两个一是tool_choiceauto把工具选择权交给模型但执行权由代码控制二是把工具执行结果和异常严格按照tool角色回传给模型保证观察环节不丢失。很多初级实现会在抛出异常后直接结束流程结果模型连自我修正的机会都没有。这个骨架跑通之后再往里面加日志、权限校验、二次确认都是顺理成章的事。2.4 为什么这样简单的结构够用有人会问市面上不是有很多复杂的 Agent 编排框架吗为什么先给这么简陋的一个循环我的观点是Agent 的复杂度应该有节制。大部分业务问题比如客服工单处理、日程安排、内部知识检索本质上都在“理解需求—查数据—给结果”这个范围内一个循环加五个工具完全够用。框架能帮我们省掉一些样板代码但也带来不少隐性成本抽象层过多出了问题时排查链路变长调度逻辑升级频繁代码和框架版本容易脱节外部依赖一多安全边界需要额外防护。所以我建议先自建一个只有循环、工具注册、日志的最小系统跑通一个真实任务后再根据痛点决定是否引入框架。没有足够理由前不要为“未来的扩展性”预支今天的复杂度。3. 驾驭的关键让 Agent 不乱跑、不撒谎、不瞎折腾3.1 上下文管理长对话不等于记忆Agent 最容易翻车的点之一是打着“有记忆”的旗号把所有消息都堆进上下文。模型输入窗口再大也是有限的对话进行到二十轮之后早期信息要么被截断要么被大量工具返回内容淹没。更麻烦的是每次请求都把全部历史发给模型费用和延迟都会线性增长。我见过一个 Agent 处理三十分钟的对话后单轮请求体积膨胀到原本的四倍响应速度几乎不可用。合理的做法是分级管理上下文短期上下文只保留当前任务最近几轮对话中期信息通过摘要压缩每隔几轮把前面的内容用模型生成一段摘要长期事实则抽出来写入结构化存储需要时再检索。我在客服场景里实践过后上下文体积稳定在初始大小的两倍以内效果也没有明显下降。记住上下文管理不是把更多文字塞给模型而是让模型在有限的窗口里看到最相关的信息。3.2 工具白名单Agent 只能在“跑道”里行动给 Agent 工具授权时我遵循的原则是“最小权限白名单制”。通俗地说就像给实习生一张工作清单而不是把公司门禁卡交给他。系统里有的工具可能很多但单个 Agent 只需要暴露完成当前任务必要的三五个。权限越宽出问题的概率越高模型选错工具的后悔成本也越大。工具描述本身也是一种约束。描述要写清楚使用前提、参数含义、返回结果和典型错误最好还给一个或者两个示例。我见过一个 Agent 反复调用错误的工具本质原因是两个工具描述太过相似“创建用户”和“更新用户”就差一个词模型经常混。后来我特意在描述里加了一句“当用户表示已有账号需要变更信息时使用更新首次创建时使用新增”误调用的比例立刻降了下来。对于发邮件、删除数据、修改生产配置这类有副作用的操作我强烈建议加人工确认环节。具体做法是Agent 在发起这类工具调用时不直接执行而是把待执行的动作展示给用户选“确认/取消”等确认后才真正执行。虽然增加一步交互但在真实业务中这个确认按钮能挡住大量潜在的“好心办坏事”。3.3 输出校验把幻觉拦截在交付前大模型的一大毛病是“一本正经地胡说八道”Agent 把这个毛病放大了因为它的输出会被当成真实结果直接进入下游。应对办法只有一条对所有关键输出做校验。第一步是格式校验。如果 Agent 需要返回 JSON就明确要求它返回一个符合预定义 Schema 的对象再用程序解析校验不合格的直接自动重试一次。第二步是业务规则校验。比如客服场景里要求订单号必须匹配ORD-开头加八位数字的格式就用正则先查一遍日期字段要落在合理范围内就做范围判断。第三步是源数据复核让模型在生成结论之前先引用它所用到的工具返回记录再由校验模块核对引用是否存在。我把这套逻辑总结成一句话不要相信模型的自我报告。模型说“已发送邮件”不算数必须把发送接口的真实返回值作为唯一依据。凡是无法用工具结果验证的内容一律按未完成处理。这种强校验在早期会带来一些开发量但它正是 Agent 能否从“演示”走向“生产”的分水岭。3.4 打断与兜底当好驾驶员Agent 再怎么聪明也只是一套软件系统必须有外部给它踩刹车。我给 Agent 设的第一道刹车是max_steps也就是单任务最大循环次数。第二道刹车是“重复检测”如果模型连续两轮发起完全相同的工具调用、拿到相同结果基本可以判定陷入死循环应立即终止并要求人工介入。第三道刹车是超时控制单个工具调用超过设定阈值就返回超时错误让模型自己决定换路径还是放弃。别忘了给用户留一个“打断”的入口。Agent 处于自主执行状态时用户可以输入“停一下”“改方案”之类的指令这需要代码每轮循环前检查是否有外部新消息进来。我一开始没做这个功能测试时只能等 Agent 把流程跑完才能干预体验很差。后来在循环入口加了一个消息队列检查只要用户中途发来新指令就立刻中断当前计划把新指令作为最高优先级输入。记住Agent 是替你执行任务不该对你的判断形成阻碍。4. 从 Hello World 到真实任务一个完整的打磨案例4.1 选场景客服工单的自动分类与初步回复挑选第一个真实场景时我建议找“频率高、动作单一、容错可控”的任务。太复杂的场景会让问题定位变得困难容错低的场景第一轮上线压力太大。我在这里拿“客服工单的自动分类与初步回复”举例这是很多业务系统都需要的功能也足够体现 Agent 的典型动作链。假设工单系统每天收到上千条用户反馈每条工单包含“标题”和“描述”两段文本。需要 Agent 做三件事把工单分到四个类别之一订单查询、售后服务、建议反馈、投诉判断优先级高/中/低根据类别和内容草拟一段给用户的初步回复。历史积累了几千条已人工处理的工单正好可以用来对比效果。4.2 第一次尝试一个“万能 Prompt”引发的崩盘我的第一版实现极其天真把分类规则、优先级规则、回复写作规范、示例数据全部塞进一个 Prompt希望模型一次性输出完整结果。结果相当难看分类准确率只有四成左右输出的 JSON 经常缺字段或者格式错误还有不少请求因为生成内容太多导致超时。整个反馈循环特别慢每条工单浪费的 Tokens 也高得离谱。复盘时意识到问题不是模型不够聪明而是我把太多认知负荷压在一次生成里。模型既要判断类别又要判断优先级还要构思回复语气同时维护一个复杂的输出格式。任何一个环节出错都会连带其他环节崩掉。这就像让一个新员工同时干接线员、投诉专员、质检员三份工作不崩溃才怪。4.3 拆成三步后效果发生了质变第二步实施的是“窄任务拆分”把原来一大步拆成三个顺序步骤每步只做一件事。第一步做分类Prompt 只让模型输出一个类别值可选枚举写得很明确并附上每类两个历史工单作为示例。例如请把以下工单分到四个类别之一只能输出 JSON{category: order_query | after_sale | suggestion | complaint} 工单标题{title} 工单描述{description} 示例1标题“发货后一直没物流更新”描述“订单显示已发货三天物流一直停留在原地”结果{category: order_query} 示例2标题“包装破损”描述“收到的箱子已经被压坏里面的产品也有划痕”结果{category: after_sale}第二步做优先级判断。这一步不再重新阅读原始工单全文而是把第一步的类别、工单标题以及一些关键信号词比如“两次”“加急”“破损”等作为输入让模型只输出高/中/低三档。第三步生成回复草稿时先使用工具查询该工单关联的订单信息再把订单数据和前两步的分类结果一起放进模板生成一段带占位符的回复由程序负责填充真实订单号等信息。三个窄步骤分别做质量验证后分类准确率从最初的四成提高到了八成六JSON 格式合规率接近百分之百整体耗时反而下降了五分之一。更让我意外的是因为每步输出都在受控范围内出问题时定位特别快分类错了查第一步优先级不对查第二步不会出现“整体结果很怪但不知道怪在哪”的局面。4.4 Prompt 模板写法与参数调优经过这个案例我总结了一套适合 Agent 内嵌任务的 Prompt 写法。第一输出格式优先无论什么任务都在开头就写明“只输出符合 XX Schema 的 JSON”例如{category: order_query | after_sale | suggestion | complaint}比不加约束的自然语言容易解析得多。第二枚举值要给全用竖线或分隔符把所有候选值列出来不要写“根据内容判断类型”这种模糊指令。第三用少量高质量示例每个类别给两个左右的真实样例比给二十个相似样例更有效质量永远比数量重要。参数调优方面我基本固定为分类、提取这类确定性任务temperature设置为 0 或 0.1生成回复内容的步骤可以放宽到 0.3 到 0.5但绝不超过 0.7否则语气会飘。max_tokens建议按步骤分别设置分类步骤给很小额度回复生成步骤给充足额度。还有一条容易被忽略每个步骤之间最好用程序做字段校验不合格就让模型基于错误信息重试一次。无限重试是最容易失控的配置最多重试两次就要转入人工。5. 真实运行中的成本、速度与故障排查5.1 Token 耗在哪你可能没注意的隐性开销上线前我估算过成本自以为对每次调用的 Token 量心里有数。结果跑到第三天的账单还是让我清醒过来Agent 的 Token 消耗远不是“平均请求长度乘以次数”那么简单的估算它有三个隐藏开销容易被忽略。第一个是工具描述的系统开销。每轮循环都会把工具 Schema 跟着请求发过去工具一多描述一长这部分的 Token 是固定的不随业务变化。假设五个工具的描述加示例共八百个 Token十步循环就是八千个完全不可忽略。第二个是工具返回结果的重放开销。模型每轮都要重新看到上一轮工具返回的内容如果某个工具返回了一个几万字符的日志后面的每一步都在帮它重复计费。第三个是历史消息的累加效应。带上下文的长对话会让每一轮请求越来越长越到后面费用越高。对策也很直接工具描述尽量精简到一句话内参数枚举用关键字而不是长句子工具返回结果在使用前先截断只保留最关键字段再塞进消息对历史对话做摘要早于某个窗口的消息压缩成一小段小结。我按这三条做了一轮优化同样业务量的 Token 成本大概压低了四成。5.2 速度瓶颈模型推理 vs 外部服务速度优化要先知道瓶颈在哪。我做过一次简易埋点把一次工单处理任务拆成三段时间模型等待时间、工具执行时间、校验时间。数据分布大致是模型占百分之六十工具占百分之三十校验占百分之十。这个分布在不同业务里会变但模型等待时间几乎总是大头所以想提速度时先别急着让外部接口“变快”先看看能不能减少模型交互次数。减少模型调用的常见办法是批处理把好几个独立工具请求合并成一轮调用让模型一次性发起多个工具调用然后并行执行。另一个办法是给常见问答做精确缓存如果用户请求和过去某个请求完全一致直接返回缓存结果不浪费一次模型调用。缓存命中率做得好平均响应时间能降一半以上。还有一点工具调用如果真的耗时太长可以考虑异步化先把任务进度返回给用户等工具结果出来后再推送最终结果避免用户在屏幕前干等。5.3 怎么给 Agent 排错Agent 项目上线后最折磨人的不是开发而是排错。传统程序出错有堆栈、有日志Agent 出错常常表现为“结果看起来合理但实际上跑偏”或者“某个环节悄悄失败”。我后来养成了一个固定排错流程每次出问题都按这个顺序走效率会高很多。第一步找到那一次的完整消息序列。需要看到从用户输入、模型每一轮的完整输出、每个工具请求和返回值一直到最终结果缺任何一环都无法定位。第二步定位是哪一类错误。我把常见错误先分了四类如下表所示。错误类型典型表现排查重点解析失败模型返回 JSON 模型无法解析或字段缺失检查 prompt 输出格式约束和示例必要时降低 temperature工具参数错误调用了工具但参数缺项或格式不对看模型收到的工具描述是否足够清晰枚举值是否漏写幻觉引用Agent 声称找到了数据但工具返回值里根本没有校验最终答案里每个事实点是否都能追溯到工具记录循环死转同一工具反复调用结果不变检查是否有重复检测和最大步数限制第三步把定位到的问题转成新的约束写进 Prompt 或校验逻辑。排错不是修完就完要把这次教训沉淀成一条规则比如“凡是涉及订单号的回答必须先调用查询工具禁止直接生成订单状态”。按这个流程跑下来我基本能在半小时内定位大多数线上问题而不再像早期那样靠蒙。5.4 给 Agent 装“黑匣子”日志与可观测性Agent 的排查难点在于它是多步、多工具的传统的行日志根本不够用。我的建议是给每次完整任务生成一个唯一的追踪 ID然后把所有日志串联起来。每一条结构化日志至少要包含这些字段时间戳、追踪 ID、步骤序号、事件类型、涉及的模型 Tokens、工具名称、耗时、消息摘要。还有一个账号长期用起来最舒服的日志配置把每一步的“模型发起工具调用参数”“工具返回结果的前若干字符”都记录到文件必要时候还要把完整消息序列快照保存方便回溯。我习惯给每种事件单独记一条 JSON 日志而不是塞进普通文本日志里这样写检索脚本特别方便。上线后我还设了几个基础告警平均响应时间超过阈值、单任务 Token 消耗超过阈值、工具错误率超过阈值加起来基本能做到“有故障先不慌看日志定位”。6. 更复杂的玩法我为什么不急着上多 Agent 与长期记忆6.1 什么时候才需要多 Agent在社区讨论里多 Agent 编排总是显得很酷但真实业务里能用上它的场景其实不多。我判断“要不要上多 Agent”的标准很朴素单 Agent 的上下文是不是已经被互相干扰的任务塞满了不同子任务之间是否需要隔离权限子任务的失败是否可以互不影响只有这些答案为“是”才值得考虑。举个例子一个自动生成营销内容的系统可能包含“市场数据查询”“内容创作”“合规审核”三类职责。如果让同一个 Agent 既查数据又写文案又做审核它很可能在写文案时受到查询内容的干扰或者在审核时因为和作者共享同一套上下文而“护短”。拆成三个 Agent 后数据 Agent 只负责输出结构化数据内容 Agent 只管写作审核 Agent 只做合规判断每个 Agent 的 Prompt 更简短权限也能分别收紧。这是多 Agent 架构最有价值的场景。6.2 两种协作模式主从编排 vs 协商式多 Agent 的协作模式大致分两类主从编排和协商式。主从编排是一个主管 Agent 负责拆解任务、分配子任务、汇总结果子 Agent 只听从安排不互相沟通。这种模式结构清晰适合流程固定的业务也容易做日志跟踪。缺点是主 Agent 本身会成为新的瓶颈它的规划和调度质量决定了整个系统的表现。协商式则是多个 Agent 共享一个“任务黑板”轮流阅读和补充内容通过多轮交流逐渐收敛到最终方案。这种模式更接近人类团队的协作方式能处理更开放的创造性任务但风险和成本都高得多对话轮数不固定每个 Agent 都可能偏离主题Token 消耗也成倍增长。我目前只在探索项目里用过协商式生产系统里一律采用主从编排原因很简单可预测性和可控性比花哨的协作机制重要得多。6.3 长期记忆的三种姿势不少团队一上来就想给 Agent 做长期记忆动不动就要上向量数据库。我的经验是长期记忆至少有三条路选哪条取决于业务真正需要什么。第一是向量检索引擎适合“按语义找相似内容”的场景比如在历史工单库里找类似问题的解法效果不错但对事实类查询不够精确检索结果还经常夹带噪音。第二是结构化存储把订单、用户、产品这类事实放进传统数据库查询时用工具接口访问精确但需要人工定义数据模型。第三是摘要归档就是把每次都生成一份任务摘要存起来下次遇到相似任务时可以快速参考实现最简单但会丢失细节。给一个务实的建议先把短期上下文管好把工具结果保存好等发现非跨会话记忆不可的时候再开始做长期记忆。过早引入复杂的记忆系统大概率会在检索质量问题上浪费大量时间而核心业务价值未必有提升。6.4 我为什么刻意保持“克制”带过几个 Agent 项目后我越来越认同一个观点克制是复杂度控制的重要原则。单一 Agent 能搞定的任务不拆短期上下文能承载的信息不存长期一个循环加几个工具能解决的业务不上框架规则校验能兜底的风险不指望模型自觉。这个原则让我少踩了很多坑。尤其在生产环境里性能稳定、成本可控、错误可解释这三件事比“看起来智能”重要得多。我的做法是让 Agent 在约束范围内跳舞给它清晰目标、给它白名单工具、给它强校验、再给它刹车。模型负责发挥灵活性的部分规则负责兜住风险的部分两者配合得越默契系统才越接近“好用”的状态。我个人在实际项目里反复验证过的结论是先约束再赋能先单 Agent 跑通再加多 Agent。任何一个看起来失控的 Agent多半不是模型不够聪明而是我们没给它划清楚跑道。如果你正准备动手做一个 Agent建议从最小骨架开始先把循环跑通再把工具接上最后加上校验和日志一步步稳着来。等你经历过一次从“演示惊艳”到“上线翻车”再到“逐步修稳”的完整周期你会更理解什么叫驾驶一辆智能体——方向盘始终要握在自己手里。