AI agent设计的方法与技巧

做 agent 最容易卡在三个地方：不知道该拆成单 agent 还是多 agent、工具和上下文越堆越乱、上线后效果和账单都说不清。这篇不讲概念史，只给一套设计顺序和检查清单，帮你把「能跑个 demo」变成「能交付、能算账、能查出问题」的东西。价格和额度类数字不写死，去站内对应页面核对。

这篇只讲设计顺序：先定边界和交付标准，再做工具与状态，接着布控制点，最后补验收和成本口径。每一步都有能落地的动作，不解释概念史。价格、额度、跑分这类数字一律不写死，去站内对应页面看当时的数字。

它适合已经能跑通一次调用、想把它做成能交付的系统的开发者。如果你的任务本身还在探索、目标每周都在变，这套顺序帮不上忙，先用固定工作流加人工更快。另外，涉及对外发消息、付款、删数据这类动作，下面所有设计都要默认加人工确认。

先把任务边界和交付标准定死

第一步不是选模型，是写一句能被别人检验的话：这个 agent 收什么、吐什么、什么算做完。输出形态先定下来——是结构化字段、是一串可执行动作，还是给人看的说明，这决定了后面工具怎么描述、验收怎么判。句式可以套用「输入是……，输出是……，当……时算完成」。写不出这句，先别动手。

接着列「不该由它做」的清单。付款、删除、对外发消息、写生产库这几类默认走人工确认，不是不信任模型，是这类动作出错后没法低成本回滚。把成功标准也拆成可判定的几条，比如关键字段命中、动作执行成功、需要人工接管的比例，模糊的标准会让后面根本没法验收。

工具宁少勿多。每个工具要写清入参、出参、失败时返回什么，尤其失败返回——返回一句「失败了」模型只会反复重试同一个调用。发现两个工具职责重叠就合并，重叠是模型来回试错的主因。参数命名尽量和业务词一致，别用内部缩写。

状态分两层看：会话内的短期信息放上下文，跨会话的事实和进度落外部存储。别指望模型记住上一轮说过什么，长文档走检索而不是整段塞进去。上下文按三档排——必须常驻的、用到再取的、只做检索的，常驻那档越短越稳，膨胀通常从这里开始。

术语口径不统一时，同一个词在工具描述和验收标准里意思不一样，模型和人都会判错。可以对照站内的术语页把说法统一，避免后面返工。

控制点放在高风险动作之前：写库、发消息、下单这类，先输出待确认草稿，人点了才执行。另外设步数上限和超时，超限直接转人工，并把中间过程一起带出来，避免无限循环空烧额度。这两个是基本盘，缺一个都会在灰度阶段暴露。

纯内部、可回滚、出错成本极低的场景可以少设闸门，否则流程会重到没人愿意用。判断标准是：这个动作错了，恢复要花几分钟还是一次沟通就能解决。超过一小时的，就值得加确认。

准备一小批固定用例，覆盖正常、边界、故意刁难三类。每次改动跑同一批，看通过率和人工介入次数，别靠手感判断。用例不必多，但每次都要跑同一批，否则改动前后没法比较。刁难类用例主要用来暴露工具描述的歧义。

成本要分清构成：调用模型的 token、工具自身的费用、检索与存储、重试带来的额外调用。重试通常是月账单里最不可控的一块，也最能通过合并工具和收紧返回内容来压下去。把「单次任务平均成本」当成核心指标，对照站内的费用计算与价格追踪页面核算，价格和额度以页面当时的数字为准。

单 agent 和多 agent 该怎么选？

先默认单 agent 加清晰的工具列表。只有当子任务边界清楚、彼此几乎不需要共享中间状态、且串在一个提示里已经明显互相干扰时，再拆多 agent。拆之前先算清多出来的调用次数和失败重试成本，很多所谓需要多 agent 的场景，其实只是工具描述没写清。

怎么判断 agent 是提示词问题还是设计问题？

看失败是不是重复出现同一种形态。同类错误反复出现，多半是工具描述、状态存储或闸门位置的问题，改提示词只能压一阵；错误分散、每次不一样，才更像提示与上下文的问题。改动前先固定一批用例，改完跑同一批再判断有没有真的变好。

agent 上线后成本失控通常出在哪？

多数不是单价，而是重试和上下文膨胀：工具失败后模型反复换着试、每轮都把历史全带上、检索结果一次塞太多。先给重试设上限、压缩常驻上下文、把长内容改成按需检索，再去看模型单价。具体价目和额度变动到站内 /official-api 与 /price-watch 核对当时的数字。