最近团队里一直在打磨一个内部项目代号就叫agency-agents。这个词最近在圈子里出现的频率越来越高看到热搜里挂着它我觉得有必要聊聊一个容易被忽略的点agents 本身不难做难的是让 agent 拥有真正的“agency”——也就是它在多大程度上有自主推进任务的空间。市面上大多数 demo 级别的 agent本质还是“对话 调接口”的组合真正敢把决策权交给模型的场景少之又少。这篇文章是我在实际搭建一个可用系统过程中的完整复盘包括我为什么这么设计、踩了哪些坑、最后怎么修的。如果你正准备把一个“会聊天的原型”升级成“能自己干活的系统”这篇应该对你有用。为了让你有个具体的认知锚点先说我做的这个项目解决什么问题输入一批原始需求agent 需要自主完成“理解目标 → 拆解步骤 → 调用工具 → 校验结果 → 迭代修正”的完整闭环整个过程中人工不逐条干预。这跟普通的 ChatBot 套 OpenAI API 不一样它涉及任务循环、工具注册、上下文管理、多智能体协作、异常恢复。下面我把整个设计决策和踩坑过程拆开讲。1. 为什么“agency”突然成为智能体项目的关键词先厘清一个概念问题。很多人把 agent 理解成“能调用工具的聊天机器人”这个理解在技术实现上没问题但在产品定位上会出大问题。工具调用只是手段agent 的核心价值是在没有明确指令的情况下能根据目标自主决策下一步做什么。这就是 agency。打个比方一个实习生你告诉他“把这个表格整理好”他可能会问你“按什么规则整理要不要去重输出什么格式”——这是工具型 agent。另一个实习生在明确目标后直接开干遇到边界情况先按合理默认值处理卡住了才来问你——这是有 agency 的 agent。1.1 从“可用工具”到“敢放权”的转变我早期做 agent 的时候思路很朴素把大模型当一个“调度器”我预设好所有工作流模型只是根据用户输入选择一个预设路径执行。这种做法稳定但本质上还是流程引擎不是智能体。后来我评估了几个公开的 agent 框架在实际任务上的表现发现一个规律当任务复杂度上升时流程图预设的维护成本是超线性增长的。你需要考虑所有分支、所有异常、所有组合这个复杂度很快就超出人力能覆盖的范围。真正让我下定决心转向“自主决策”方向的是一个数据清洗任务——预设流程处理了 80% 的常规情况剩下 20% 的边界情况把流程图搞得一塌糊涂。与其穷举所有可能性不如让 agent 自己判断“这个字段缺失最合理的做法是什么”。这里面有一个关键的心态调整从“我要预先定义一个完美的流程”变成“我要定义一个足够好的决策框架 兜底机制”。这个框架包括目标的描述方式、可调用的工具集合、决策的边界条件、以及出错后的恢复路径。agent 在这个框架内有充分的自由度但框架本身是可控的。1.2 这个项目里到底需要什么样的自主性回到agency-agents这个项目我给它定的目标是中等复杂度任务的端到端自动化。具体来说任务是“给一批原始的产品反馈文本自动生成结构化的问题分类报告并标注重度、提出建议动作”。这个任务的特点是原始输入格式不可控会出现各种噪音分类体系虽然预设了但边界案例多需要 agent 在模糊地带做判断最终交付物有质量标准不是“生成了就行”而是要“可用”这个定位决定了 agent 不能只是“根据输入调一次分类 API”。它需要具备的能力包括识别输入中缺失的信息、决定某些模糊文本应该归入哪个类别且说明理由、发现自身分类结果自相矛盾时主动修正。这个过程中我可以接受 agent 在 80% 的情况下自主决策但要求它在 20% 的情况下例如识别到重大风险、或置信度极低时能主动“求助”而不是硬着头皮往下走。这里插一句团队内部争论过的设计是让 agent 尽可能自主地跑完全程还是把任务切小、每步都汇报两个方向我都试过。前者效率高但中间过程难控制后者可控性强但交互次数爆炸、用户体验也差。最终我们采取的方案是“分层汇报”低风险步骤完全自主高风险步骤强制检查点。这个“风险”的判定标准是硬编码在任务循环中的不是交给模型自己判断——这非常关键下面会细说。2. 自主决策框架设计从提示词堆砌到结构化任务循环初版系统我把所有指令都写在 system prompt 里写了两千多字试图用自然语言把任务边界描述清楚。结果测试时模型经常“过度表现”——比如在分类任务中擅自合并了两个细分类别理由是“我觉得这两个语义上相近”。模型说得有道理但客户不认这个。这说明一个问题**把决策规则写在提示词里本质上还是在赌模型的“自觉性”而且这玩意儿不稳定。**后期我把架构改成了结构化任务循环效果稳定得多。2.1 任务循环的核心结构Perceive → Decide → Act → Verify我实现的循环本质上是一个强化学习式的闭环但实现上完全基于大模型的文本输入输出。核心代码如下class AgentLoop: def __init__(self, tools: list[Tool], policy_model, checker_model): self.tools {t.name: t for t in tools} self.policy_model policy_model # 决策模型负责任务规划和工具选择 self.checker_model checker_model # 校验模型负责结果质量检查 self.memory [] # 保存当前任务的上下文轨迹 self.checkpoints [] def run(self, goal: str, max_steps: int 20): state {goal: goal, context: self.memory, result: None} for step in range(max_steps): # 1. Perceive: 让模型基于当前状态决定下一步动作 action self.policy_model.decide(state) # 2. Decide: 判断风险等级规则内判断不靠模型自觉 if self._is_risky(action) and not env.is_approved(action): return self._request_human_checkpoint(state, action) # 3. Act: 执行工具调用 observation self._execute_action(action) # 4. Verify: 校验观察结果是否满足目标 done, problems self.checker_model.verify(state, observation) state self._update_state(state, action, observation, problems) if done: return self._build_result(state) raise MaxStepsExceeded(state)这段代码对应的设计决策是决策模型和校验模型分离。让同一个模型既当运动员又当裁判测试下来容易出现“自我感觉良好”的问题——它觉得自己的结果没问题但实际交付质量不合格。我用一个独立的校验模型可以理解为不同温度和 prompt 的同一模型调用来检查结果效果提升明显。2.2 为什么我把“风险判定”从提示词里摘出来这是我踩过最深的坑之一。一开始我在 system prompt 里写“如果你认为当前操作可能对用户造成重大影响请先征求用户同意”。实验下来模型对“重大影响”的理解很不稳定。有时候它觉得调用一个只读 API 都需要确认有时候它对“删除数据库中的表”视而不见。这不是模型笨而是“重大影响”这个概念对模型来说太模糊了。现在的做法是把风险判定做成硬编码规则比如RISKY_ACTION_PATTERNS { write_operation: [update, delete, insert, drop, alter], external_communication: [send_email, send_message, post_webhook], high_cost: [llm_call_batch, openai_batch_api], } def _is_risky(action): action_name action[name].lower() for category, patterns in RISKY_ACTION_PATTERNS.items(): if any(p in action_name for p in patterns): return True return False模型的任务是“提方案”规则的职责是“拦操作”。这个分工清晰以后整个系统的安全性立刻上了一个台阶。团队里有人问我为什么不把这部分逻辑也学会让模型判断我的回答是规则的归规则模型的归模型。只要是能用确定性逻辑表达的约束就绝对不要依赖概率性输出。这是 AI 系统设计的铁律对你的 agent 项目同样有效。2.3 步骤间的“状态传递”与上下文管理自主决策还有一个容易出问题的地方上下文管理。跑多步任务时如果每步都把全部历史记录塞给模型很快 token 就会爆炸而且模型会被早期信息干扰。我采用的方案是分层记忆当前动作上下文只放最近 2-3 步的工具调用与结果任务级记忆放 goal、已完成步骤摘要、当前待解决的阻塞点长期记忆放这个任务类型沉淀下来的经验教训跨任务复用这个三层结构的核心是“摘要机制”def summarize_step(step_action, step_observation, last_summary) - str: # 用一次轻量模型调用把当前步骤关键信息压缩成一行摘要 prompt f将以下步骤信息压缩为不超过50字的摘要保留关键数据变更、错误信息、当前进度。 之前的摘要{last_summary} 本次动作{step_action} 本次结果{step_observation} 输出摘要 return light_model_call(prompt)这个设计让 agent 在多步任务中的上下文消耗非常可控。不过要注意摘要本身会带来信息损失所以对于关键数据例如最终写入数据库的某条记录的 ID我会直接存入一个结构化变量里不走摘要确保任何时刻都能访问到准确值。3. 工具调用层业务能力如何接入 Agent 而不失智框架搭好之后重点就在于工具层。很多 demo 项目跑不起来不是模型不行而是工具的定义方式太粗糙。我见过有人把工具描述写成“获取用户订单数据”然后参数就一个 user_id提交给模型之后模型经常会搞不清要传什么。本质上工具的“描述质量”直接决定模型使用工具的准确率。3.1 工具 Schema 设计的“自我测试”标准在设计工具时我给自己定了一个标准如果一个工程师看了这个工具描述后还需要私下问我如何使用那它就没资格交给模型。具体来说每个工具的 definition 里必须包含工具的功能边界什么情况该用、什么情况不该用每个参数的约束条件格式、范围、是否必填返回值结构成功时的结构、失败时的错误码含义典型使用示例至少一个正面示例举个例子我注册的一个工具是“按日期范围获取反馈数据”{ name: get_feedback_by_date_range, description: 获取指定日期范围内的用户反馈文本列表。适用于按时间筛选反馈数据用于后续分类分析。当用户需求涉及的是一段连续日期时使用。不可用于按关键词搜索反馈。, parameters: { start_date: {type: string, format: date, description: 开始日期格式YYYY-MM-DD含当天}, end_date: {type: string, format: date, description: 结束日期格式YYYY-MM-DD含当天不可早于start_date} }, returns: { type: object, description: 返回包含feedback_list的数组每个元素含id, content, created_at字段失败时返回error_code和error_message }, example: get_feedback_by_date_range(start_date2024-03-01, end_date2024-03-31) }这个描述比常规的参数列表多了“典型使用示例”。实测下来增加 example 字段之后模型选择工具的准确率显著提升。原因是模型在 zero-shot 场景下对纯描述性的 JSON Schema 理解能力有限但给一个具体例子就立刻能明确“哦是这个意思”。这个灵感来源于我看的一些 LLM 应用最佳实践但真正效果是我自己实验对比出来的。3.2 工具“翻车”后的容错与重试策略工具不可能不报错做完工具层之后我马上遇到一个新问题工具报错agent 怎么办。初期是直接把错误信息抛回给模型结果模型有时候会陷入死循环——“我再调一次试试说不定就好了”。这浪费了 token也让系统卡住。我后来设计了分层容错机制参数类错误如日期格式不对、参数缺失让模型看错误信息重新决策这没问题因为重新决策大概率能修好业务类错误如数据库里没数据、接口返回 500不直接让模型重试而是先写入上下文标记“此路不通”并提示模型更换路径连续失败超过 N 次格式化失败信息转入人工检查点不无限消耗卡这里有个细节值得分享给模型看的错误信息必须经过一层“翻译”。你不能直接把 Python 的 traceback 塞给模型——那里面全是模型不关心、反而会起误导作用的底层信息。我会用一个简单的 parser 把错误信息整理成“错误原因 可操作建议”例如错误日期范围无效start_date 不能晚于 end_date 建议请检查你的输入参数start_date 需要在 end_date 之前这层翻译大大减少了模型因为看到技术性错误信息而胡乱操作的可能。3.3 工具数量与“选择成本”的取舍工具越多的系统模型选择工具的出错率会上升这是一个实测现象。当我给 agent 注册 30 个工具时即使每个工具都描述得再清晰模型也开始出现混淆——它可能把 A 工具的某个参数错误地用在 B 工具上。经过多次实验我基本确认了当前模型的“舒适区”是 10-15 个工具。这个数字不是理论推导而是实际测试中准确率明显开始下降的临界点。因此我在架构上做了一层工具分组路由先由一层模型决定“当前任务属于哪个域”再在这个域内选择具体工具。每个域的工具数量控制在 10-15 个以内。比如“数据查询域”“内容生成域”“任务管理域”。这样既保留了大量工具能力又不超出模型的实际选择能力。4. 多智能体协作为什么我选择了“主管 专员”模式单一 agent 处理复杂任务会遇到两类问题一是上下文太长导致关键信息丢失二是不同环节需要的能力差异太大比如分类判断和后续建议生成是两个风格的任务。所以我在项目中期引入了多智能体协作。一度也考虑过全自由联网的“群体智能”形态但实测后选择了更可控的“主管 专员”结构。4.1 两种主流协作模式的实测对比我实际跑过的两种模式对比结果如下模式优点缺点我的实测观察群聊式协作所有 agent 平等互相广播消息信息流动性好可能产生“意外创新”决策混乱、token 消耗巨大、没有明确的负责人模型 A 提出的方案模型 B 不认可双方陷入“你说得对但我觉得不行”的礼貌循环任务推进缓慢主管 专员模式主管负责任务拆解与进度管理专员执行具体子任务职责清晰、每个模块上下文短、可独立调优主管若拆解不当会形成瓶颈主管的拆解质量决定了系统上限但整体稳定性和可预测性远好于群聊式我最后选择了“主管 专员”。“主管”不负责具体业务处理而是负责拆解目标、分发任务、汇总结果、检查对齐。每个“专员”只负责一个特定子任务上下文短暂而聚焦。这个结构的另一个好处是单个专员的工具注册数量可以集中在自己的“专长域”内避免大而全的工具选择压力。4.2 智能体之间到底该传什么这是我在设计多 agent 通信时踩过最深刻的坑。最初为了让协作更顺畅我让各专员之间直接传递自然语言的“分析结论”。结果很快乱了——因为每个 agent 的措辞习惯不一致A 说的“可能有点问题”在 B 那里根本没当回事。后来我把 agent 之间的通信内容格式化了。传什么传结构化指令 结构化结果。自然语言只作为补充说明。例如{ task_id: subtask_0001, input_summary: {feedback_count: 230, categories: [bug, feature, complaint]}, required_action: classify_feedback, constraints: {confidence_threshold: 0.8, output_fields: [category, reason, suggestion]} }这样做的效果是上游 agent 的输出可以稳定地成为下游 agent 的输入而不是靠“理解”。系统可调试性也大大提升——任何一步输出不对都能通过检查结构化字段立刻定位是哪个环节出了问题。这个改动也直接影响了我的最终代码结构我甚至给 agent 间通信定义了一套轻量的“协议”本质是一个 JSON Schema 的约束确保任务在传递过程中不丢失关键信息。4.3 预算与延迟的现实考量多 agent 协作不是免费的。我算过一笔账同样是处理 100 条反馈数据“单 agent 长上下文”模式大约消耗 15k token而“主管 专员”模式因为引入了多轮任务汇总和结果传递大约消耗 25k-35k token。成本直接翻倍。延迟上也类似——每个 agent 都要跑一次模型调用链路一长响应时间就慢。我的优化手段是把“串行传递”改为“并行分组”。主管拆解任务后如果多个子任务相互独立就一次性分发到多个专员并行执行主管只负责最终汇总。这在处理批量数据时效果极其明显总耗时从串行的 5 分钟降到并行后的 40 秒。当然这对底层的并发调度有要求我用了 asyncio 的事件循环来管理多 agent 协同而不是简单的顺序等待。如果你打算做类似系统这个“并行化”的架构设计在第一天就要想好否则后期重构成本很高。5. 实测中的翻车记录上下文污染、死循环与幻觉修正再好的架构设计也要经过真实数据的毒打。下面记录三次比较典型的翻车事件和对应的修复方案这比任何文档里的最佳实践都有参考价值。5.1 事故一长任务中“上下文污染”导致决策漂移在一次处理 500 条反馈数据的任务中跑到第 20 多步时模型突然开始改变分类规则——把原来归为“售后”类的数据改成了“投诉”并且给出的理由引用了很靠前的某条消息。我排查后发现原因是早期某条反馈文本里出现了一个特殊标记ticket_1234这种格式模型后来的注意力被这个标记吸引开始“脑补”出其实并不存在的关联规则。修复方案是两方面的。第一在任务循环里对进入上下文的文本做清洗——把原始反馈里的特殊标记统一替换为结构化占位符。第二在校验环节加入了“决策一致性检查”每隔固定步数抽取若干条已分类结果让校验模型检查是否有中途标准漂移有则回退到最近一个 checkpoint 重新执行。这两个改动让长任务的稳定性大幅提升。5.2 事故二无限循环与 token 燃烧有一个版本当某个工具返回空数据时agent 会陷入“查询 → 结果为空 → 换个条件查询 → 结果还是空”的循环。从日志看它甚至尝试了各种毫无意义的查询参数组合直到把 token 烧完。这个问题的根源在于空结果本身是一种有效结果但模型经常把“空”理解成“我没查对”于是试图再查。修复就是我前面提到的连续失败计数 路径标记。一旦某个动作连续失败超过 N 次系统会立刻标记“该路径已不可行”并明确告诉模型“不要再尝试同类查询请基于已有信息继续或向用户请求更具体的方向”。这个修复本质上是剥夺了 agent 的“无限重试权”——在真实组织里一个员工反复用同一种方法尝试 20 次失败还不换思路早该被提醒了。5.3 事故三模型生成的“幻觉分类理由”如何被拦截更隐蔽的问题是模型对某些模糊反馈的分类本身没错但它生成的理由是事后编造的。比如某条反馈说“发货太慢了”模型把它归为“物流问题”并写了一句“用户语气强烈暗示对配送时间极其不满”。但实际上用户只说了五个字根本没有“语气强烈”。我加入了一个“理由可信度校验环节”让校验模型判断理由中是否含有超出输入文本内容的推测性陈述例如“暗示”“可能说明”“明显表示”这类词出现时会标记为“过度解读”要求重写。第一次修正后分类结果的理由质量明显更贴合原文——这对我特别重要因为在这个项目的业务场景里分类理由是要直接呈现给运营团队的可信度不够会让整个系统被打上“不靠谱”的标签。5.4 兜底设计人工介入的入口到底放在哪里即便做了这么多防护我依然保留了人工介入的入口。关键是怎么设计这个入口让它既不影响效率又能真正兜住底。我的设计是三级兜底第一级风险操作前强制审批前面提到的规则第二级连续失败或低置信度时自动暂停转到人工队列第三级任务完成后生成“决策摘要”允许人工一键回滚到任意 checkpoint很多人觉得加人工入口是“不够智能”的表现但我的观点正好相反在当前的模型能力下敢于主动请求人工介入的系统才是真正可投入生产的系统。那种硬撑到底的 agent 也许在 demo 里更惊艳但上线一个月后就会在各种极端数据上把团队坑到怀疑人生。对于模型的置信度我用了两个来源的交叉验证一是模型在返回结果时附带的confidence字段——虽然这数字有时虚高但作为参考有用二是由一个独立小模型对“分类结果与原始文本的匹配度”打分。两者都低于阈值时才触发人工介入。这个双校验比单纯依赖单一模型的自信度靠谱不少。6. 评估方式如何知道你的 Agent 今天变好了还是变坏了这也是一个常被忽略的问题。最终要交付一个真正可用的系统你不能只在开发时测几个用例就宣布完成。你需要一个可重复、自动化的评估机制否则后续每次改个 prompt 都只能靠“感觉”判断有没有变好。6.1 我搭建的“回归测试集”与指标定义我建了一个包含 50 个任务样本的评估集30 个是历史跑成功过的精选任务20 个是高频边界情况如空数据、极端长文本、模糊分类、跨步骤依赖等。每次我对系统做任何改动——改 prompt、改工具描述、改决策逻辑——都会先跑一遍这个评估集对比改动前后的指标。用的核心指标有四个任务完成率跑完整个任务循环且交付物“可用”的比例平均决策步数完成同一批任务需要的步骤总数越少代表效率越高人工介入率需要触发审批或求助的任务占比越低代表自主性越强工具调用准确率工具的调用参数是否符合规范、是否选对了工具这个评估体系的建设成本投入在早期是有点烦的但后期改系统的时候真香——至少有客观数据说话而不是开发群里互相争“我觉得新版更聪明”这种毫无意义的话。6.2 长尾问题的持续再生机制评估集固定下来还有一个好处当线上跑出某个新的问题样本我会立刻把它追加进评估集。以后任何一个改动如果让这个样本重新劣化测试马上能抓到回归。这个过程我开玩笑叫“给 agent 建病历”——每一个曾经犯过的错都被记录在案随时可以被复查。长期下来整个系统的稳定性是螺旋上升的而不是靠灵光一闪。7. 给新人的建议从零搭建agency-agents的最小路径文章最后给打算自己动手做类似项目的人一条最稳妥的路径。当年我要是有这份清单能少走不少弯路。7.1 第一阶段不要追求“全自主”先跑通一个受限闭环很多人第一次做 agent 就想要一个完全自主的东西结果半年过去了还在调 prompt。我的建议是缩小范围先选一个特别窄的任务例如“把指定邮箱的附件按规则重命名并归档”跑通我刚才说的 Perceive → Decide → Act → Verify 闭环。这个阶段你只需要一个模型、两个工具、一个简单的校验逻辑。目的不是解决问题而是理解“模型自主决策时会出现哪些不可预料的边界”。7.2 第二阶段把失败案例结构化形成你的“坑位清单”第一阶段必然会翻车。每翻一次就往你的分类清单里记一笔这是哪类问题——是工具描述不清、是上下文污染、是模型幻觉、是循环重试、还是状态丢失。积累 20-30 个案例后你的系统设计会出现非常清晰的改进方向。这个阶段的核心是记录和归纳不要急着修。7.3 第三阶段加入自主能力但永远保留“安全阀”当你对翻车案例的类型有了充分认识就可以开始提升自主度——增加工具数量、增加决策自由度、考虑多 agent 协作。但每一层自主度的增加都必须同步设计对应的“安全阀”。例如增加一个新的“写操作”工具就同时增加这个工具的风险审批规则增加一个专员 agent就需要明确主管对它的监督机制。每一次放权都要有对应的刹车机制。7.4 终极提醒Agent 项目的隐藏成本全部集中在“评估”我不想展开太多口号式的鸡汤只说一个我反复感受到的事实agent 系统的研发成本和普通后端系统完全不是一个量级。普通后端你写完代码测试完就能上线agent 系统你要持续维护的是模型的决策质量——这本质上是数据标注、评估集建设、回归测试和线上监控的持续投入。要把这个成本算进预算里否则项目很容易在“演示很好但不敢上线”的尴尬阶段徘徊不前。说起最终的体会我在这个项目里最大的转变是明白了“能自主”和“该自主”是两回事。一个成熟的 agent 系统不一定要做很多勇敢的决策而是要知道哪些决策它可以自主、哪些决策必须请示。这个边界划得越清晰系统反而越强大。把这个边界设计好比让模型变聪明重要得多。如果你正准备上手做一个类似的项目建议把上面说的“风险动作规则”“校验模型分离”“结构化通信协议”这三件事先落实在代码里——它们花不了太多时间但会帮你挡掉后续绝大多数返工。欢迎在评论区聊聊你遇到的翻车案例尤其是那些反复出现同一类错误的说不定能给其他正在做 agent 的人省下一周时间。
最近团队里一直在打磨一个内部项目代号就叫agency-agents。这个词最近在圈子里出现的频率越来越高看到热搜里挂着它我觉得有必要聊聊一个容易被忽略的点agents 本身不难做难的是让 agent 拥有真正的“agency”——也就是它在多大程度上有自主推进任务的空间。市面上大多数 demo 级别的 agent本质还是“对话 调接口”的组合真正敢把决策权交给模型的场景少之又少。这篇文章是我在实际搭建一个可用系统过程中的完整复盘包括我为什么这么设计、踩了哪些坑、最后怎么修的。如果你正准备把一个“会聊天的原型”升级成“能自己干活的系统”这篇应该对你有用。为了让你有个具体的认知锚点先说我做的这个项目解决什么问题输入一批原始需求agent 需要自主完成“理解目标 → 拆解步骤 → 调用工具 → 校验结果 → 迭代修正”的完整闭环整个过程中人工不逐条干预。这跟普通的 ChatBot 套 OpenAI API 不一样它涉及任务循环、工具注册、上下文管理、多智能体协作、异常恢复。下面我把整个设计决策和踩坑过程拆开讲。1. 为什么“agency”突然成为智能体项目的关键词先厘清一个概念问题。很多人把 agent 理解成“能调用工具的聊天机器人”这个理解在技术实现上没问题但在产品定位上会出大问题。工具调用只是手段agent 的核心价值是在没有明确指令的情况下能根据目标自主决策下一步做什么。这就是 agency。打个比方一个实习生你告诉他“把这个表格整理好”他可能会问你“按什么规则整理要不要去重输出什么格式”——这是工具型 agent。另一个实习生在明确目标后直接开干遇到边界情况先按合理默认值处理卡住了才来问你——这是有 agency 的 agent。1.1 从“可用工具”到“敢放权”的转变我早期做 agent 的时候思路很朴素把大模型当一个“调度器”我预设好所有工作流模型只是根据用户输入选择一个预设路径执行。这种做法稳定但本质上还是流程引擎不是智能体。后来我评估了几个公开的 agent 框架在实际任务上的表现发现一个规律当任务复杂度上升时流程图预设的维护成本是超线性增长的。你需要考虑所有分支、所有异常、所有组合这个复杂度很快就超出人力能覆盖的范围。真正让我下定决心转向“自主决策”方向的是一个数据清洗任务——预设流程处理了 80% 的常规情况剩下 20% 的边界情况把流程图搞得一塌糊涂。与其穷举所有可能性不如让 agent 自己判断“这个字段缺失最合理的做法是什么”。这里面有一个关键的心态调整从“我要预先定义一个完美的流程”变成“我要定义一个足够好的决策框架 兜底机制”。这个框架包括目标的描述方式、可调用的工具集合、决策的边界条件、以及出错后的恢复路径。agent 在这个框架内有充分的自由度但框架本身是可控的。1.2 这个项目里到底需要什么样的自主性回到agency-agents这个项目我给它定的目标是中等复杂度任务的端到端自动化。具体来说任务是“给一批原始的产品反馈文本自动生成结构化的问题分类报告并标注重度、提出建议动作”。这个任务的特点是原始输入格式不可控会出现各种噪音分类体系虽然预设了但边界案例多需要 agent 在模糊地带做判断最终交付物有质量标准不是“生成了就行”而是要“可用”这个定位决定了 agent 不能只是“根据输入调一次分类 API”。它需要具备的能力包括识别输入中缺失的信息、决定某些模糊文本应该归入哪个类别且说明理由、发现自身分类结果自相矛盾时主动修正。这个过程中我可以接受 agent 在 80% 的情况下自主决策但要求它在 20% 的情况下例如识别到重大风险、或置信度极低时能主动“求助”而不是硬着头皮往下走。这里插一句团队内部争论过的设计是让 agent 尽可能自主地跑完全程还是把任务切小、每步都汇报两个方向我都试过。前者效率高但中间过程难控制后者可控性强但交互次数爆炸、用户体验也差。最终我们采取的方案是“分层汇报”低风险步骤完全自主高风险步骤强制检查点。这个“风险”的判定标准是硬编码在任务循环中的不是交给模型自己判断——这非常关键下面会细说。2. 自主决策框架设计从提示词堆砌到结构化任务循环初版系统我把所有指令都写在 system prompt 里写了两千多字试图用自然语言把任务边界描述清楚。结果测试时模型经常“过度表现”——比如在分类任务中擅自合并了两个细分类别理由是“我觉得这两个语义上相近”。模型说得有道理但客户不认这个。这说明一个问题**把决策规则写在提示词里本质上还是在赌模型的“自觉性”而且这玩意儿不稳定。**后期我把架构改成了结构化任务循环效果稳定得多。2.1 任务循环的核心结构Perceive → Decide → Act → Verify我实现的循环本质上是一个强化学习式的闭环但实现上完全基于大模型的文本输入输出。核心代码如下class AgentLoop: def __init__(self, tools: list[Tool], policy_model, checker_model): self.tools {t.name: t for t in tools} self.policy_model policy_model # 决策模型负责任务规划和工具选择 self.checker_model checker_model # 校验模型负责结果质量检查 self.memory [] # 保存当前任务的上下文轨迹 self.checkpoints [] def run(self, goal: str, max_steps: int 20): state {goal: goal, context: self.memory, result: None} for step in range(max_steps): # 1. Perceive: 让模型基于当前状态决定下一步动作 action self.policy_model.decide(state) # 2. Decide: 判断风险等级规则内判断不靠模型自觉 if self._is_risky(action) and not env.is_approved(action): return self._request_human_checkpoint(state, action) # 3. Act: 执行工具调用 observation self._execute_action(action) # 4. Verify: 校验观察结果是否满足目标 done, problems self.checker_model.verify(state, observation) state self._update_state(state, action, observation, problems) if done: return self._build_result(state) raise MaxStepsExceeded(state)这段代码对应的设计决策是决策模型和校验模型分离。让同一个模型既当运动员又当裁判测试下来容易出现“自我感觉良好”的问题——它觉得自己的结果没问题但实际交付质量不合格。我用一个独立的校验模型可以理解为不同温度和 prompt 的同一模型调用来检查结果效果提升明显。2.2 为什么我把“风险判定”从提示词里摘出来这是我踩过最深的坑之一。一开始我在 system prompt 里写“如果你认为当前操作可能对用户造成重大影响请先征求用户同意”。实验下来模型对“重大影响”的理解很不稳定。有时候它觉得调用一个只读 API 都需要确认有时候它对“删除数据库中的表”视而不见。这不是模型笨而是“重大影响”这个概念对模型来说太模糊了。现在的做法是把风险判定做成硬编码规则比如RISKY_ACTION_PATTERNS { write_operation: [update, delete, insert, drop, alter], external_communication: [send_email, send_message, post_webhook], high_cost: [llm_call_batch, openai_batch_api], } def _is_risky(action): action_name action[name].lower() for category, patterns in RISKY_ACTION_PATTERNS.items(): if any(p in action_name for p in patterns): return True return False模型的任务是“提方案”规则的职责是“拦操作”。这个分工清晰以后整个系统的安全性立刻上了一个台阶。团队里有人问我为什么不把这部分逻辑也学会让模型判断我的回答是规则的归规则模型的归模型。只要是能用确定性逻辑表达的约束就绝对不要依赖概率性输出。这是 AI 系统设计的铁律对你的 agent 项目同样有效。2.3 步骤间的“状态传递”与上下文管理自主决策还有一个容易出问题的地方上下文管理。跑多步任务时如果每步都把全部历史记录塞给模型很快 token 就会爆炸而且模型会被早期信息干扰。我采用的方案是分层记忆当前动作上下文只放最近 2-3 步的工具调用与结果任务级记忆放 goal、已完成步骤摘要、当前待解决的阻塞点长期记忆放这个任务类型沉淀下来的经验教训跨任务复用这个三层结构的核心是“摘要机制”def summarize_step(step_action, step_observation, last_summary) - str: # 用一次轻量模型调用把当前步骤关键信息压缩成一行摘要 prompt f将以下步骤信息压缩为不超过50字的摘要保留关键数据变更、错误信息、当前进度。 之前的摘要{last_summary} 本次动作{step_action} 本次结果{step_observation} 输出摘要 return light_model_call(prompt)这个设计让 agent 在多步任务中的上下文消耗非常可控。不过要注意摘要本身会带来信息损失所以对于关键数据例如最终写入数据库的某条记录的 ID我会直接存入一个结构化变量里不走摘要确保任何时刻都能访问到准确值。3. 工具调用层业务能力如何接入 Agent 而不失智框架搭好之后重点就在于工具层。很多 demo 项目跑不起来不是模型不行而是工具的定义方式太粗糙。我见过有人把工具描述写成“获取用户订单数据”然后参数就一个 user_id提交给模型之后模型经常会搞不清要传什么。本质上工具的“描述质量”直接决定模型使用工具的准确率。3.1 工具 Schema 设计的“自我测试”标准在设计工具时我给自己定了一个标准如果一个工程师看了这个工具描述后还需要私下问我如何使用那它就没资格交给模型。具体来说每个工具的 definition 里必须包含工具的功能边界什么情况该用、什么情况不该用每个参数的约束条件格式、范围、是否必填返回值结构成功时的结构、失败时的错误码含义典型使用示例至少一个正面示例举个例子我注册的一个工具是“按日期范围获取反馈数据”{ name: get_feedback_by_date_range, description: 获取指定日期范围内的用户反馈文本列表。适用于按时间筛选反馈数据用于后续分类分析。当用户需求涉及的是一段连续日期时使用。不可用于按关键词搜索反馈。, parameters: { start_date: {type: string, format: date, description: 开始日期格式YYYY-MM-DD含当天}, end_date: {type: string, format: date, description: 结束日期格式YYYY-MM-DD含当天不可早于start_date} }, returns: { type: object, description: 返回包含feedback_list的数组每个元素含id, content, created_at字段失败时返回error_code和error_message }, example: get_feedback_by_date_range(start_date2024-03-01, end_date2024-03-31) }这个描述比常规的参数列表多了“典型使用示例”。实测下来增加 example 字段之后模型选择工具的准确率显著提升。原因是模型在 zero-shot 场景下对纯描述性的 JSON Schema 理解能力有限但给一个具体例子就立刻能明确“哦是这个意思”。这个灵感来源于我看的一些 LLM 应用最佳实践但真正效果是我自己实验对比出来的。3.2 工具“翻车”后的容错与重试策略工具不可能不报错做完工具层之后我马上遇到一个新问题工具报错agent 怎么办。初期是直接把错误信息抛回给模型结果模型有时候会陷入死循环——“我再调一次试试说不定就好了”。这浪费了 token也让系统卡住。我后来设计了分层容错机制参数类错误如日期格式不对、参数缺失让模型看错误信息重新决策这没问题因为重新决策大概率能修好业务类错误如数据库里没数据、接口返回 500不直接让模型重试而是先写入上下文标记“此路不通”并提示模型更换路径连续失败超过 N 次格式化失败信息转入人工检查点不无限消耗卡这里有个细节值得分享给模型看的错误信息必须经过一层“翻译”。你不能直接把 Python 的 traceback 塞给模型——那里面全是模型不关心、反而会起误导作用的底层信息。我会用一个简单的 parser 把错误信息整理成“错误原因 可操作建议”例如错误日期范围无效start_date 不能晚于 end_date 建议请检查你的输入参数start_date 需要在 end_date 之前这层翻译大大减少了模型因为看到技术性错误信息而胡乱操作的可能。3.3 工具数量与“选择成本”的取舍工具越多的系统模型选择工具的出错率会上升这是一个实测现象。当我给 agent 注册 30 个工具时即使每个工具都描述得再清晰模型也开始出现混淆——它可能把 A 工具的某个参数错误地用在 B 工具上。经过多次实验我基本确认了当前模型的“舒适区”是 10-15 个工具。这个数字不是理论推导而是实际测试中准确率明显开始下降的临界点。因此我在架构上做了一层工具分组路由先由一层模型决定“当前任务属于哪个域”再在这个域内选择具体工具。每个域的工具数量控制在 10-15 个以内。比如“数据查询域”“内容生成域”“任务管理域”。这样既保留了大量工具能力又不超出模型的实际选择能力。4. 多智能体协作为什么我选择了“主管 专员”模式单一 agent 处理复杂任务会遇到两类问题一是上下文太长导致关键信息丢失二是不同环节需要的能力差异太大比如分类判断和后续建议生成是两个风格的任务。所以我在项目中期引入了多智能体协作。一度也考虑过全自由联网的“群体智能”形态但实测后选择了更可控的“主管 专员”结构。4.1 两种主流协作模式的实测对比我实际跑过的两种模式对比结果如下模式优点缺点我的实测观察群聊式协作所有 agent 平等互相广播消息信息流动性好可能产生“意外创新”决策混乱、token 消耗巨大、没有明确的负责人模型 A 提出的方案模型 B 不认可双方陷入“你说得对但我觉得不行”的礼貌循环任务推进缓慢主管 专员模式主管负责任务拆解与进度管理专员执行具体子任务职责清晰、每个模块上下文短、可独立调优主管若拆解不当会形成瓶颈主管的拆解质量决定了系统上限但整体稳定性和可预测性远好于群聊式我最后选择了“主管 专员”。“主管”不负责具体业务处理而是负责拆解目标、分发任务、汇总结果、检查对齐。每个“专员”只负责一个特定子任务上下文短暂而聚焦。这个结构的另一个好处是单个专员的工具注册数量可以集中在自己的“专长域”内避免大而全的工具选择压力。4.2 智能体之间到底该传什么这是我在设计多 agent 通信时踩过最深刻的坑。最初为了让协作更顺畅我让各专员之间直接传递自然语言的“分析结论”。结果很快乱了——因为每个 agent 的措辞习惯不一致A 说的“可能有点问题”在 B 那里根本没当回事。后来我把 agent 之间的通信内容格式化了。传什么传结构化指令 结构化结果。自然语言只作为补充说明。例如{ task_id: subtask_0001, input_summary: {feedback_count: 230, categories: [bug, feature, complaint]}, required_action: classify_feedback, constraints: {confidence_threshold: 0.8, output_fields: [category, reason, suggestion]} }这样做的效果是上游 agent 的输出可以稳定地成为下游 agent 的输入而不是靠“理解”。系统可调试性也大大提升——任何一步输出不对都能通过检查结构化字段立刻定位是哪个环节出了问题。这个改动也直接影响了我的最终代码结构我甚至给 agent 间通信定义了一套轻量的“协议”本质是一个 JSON Schema 的约束确保任务在传递过程中不丢失关键信息。4.3 预算与延迟的现实考量多 agent 协作不是免费的。我算过一笔账同样是处理 100 条反馈数据“单 agent 长上下文”模式大约消耗 15k token而“主管 专员”模式因为引入了多轮任务汇总和结果传递大约消耗 25k-35k token。成本直接翻倍。延迟上也类似——每个 agent 都要跑一次模型调用链路一长响应时间就慢。我的优化手段是把“串行传递”改为“并行分组”。主管拆解任务后如果多个子任务相互独立就一次性分发到多个专员并行执行主管只负责最终汇总。这在处理批量数据时效果极其明显总耗时从串行的 5 分钟降到并行后的 40 秒。当然这对底层的并发调度有要求我用了 asyncio 的事件循环来管理多 agent 协同而不是简单的顺序等待。如果你打算做类似系统这个“并行化”的架构设计在第一天就要想好否则后期重构成本很高。5. 实测中的翻车记录上下文污染、死循环与幻觉修正再好的架构设计也要经过真实数据的毒打。下面记录三次比较典型的翻车事件和对应的修复方案这比任何文档里的最佳实践都有参考价值。5.1 事故一长任务中“上下文污染”导致决策漂移在一次处理 500 条反馈数据的任务中跑到第 20 多步时模型突然开始改变分类规则——把原来归为“售后”类的数据改成了“投诉”并且给出的理由引用了很靠前的某条消息。我排查后发现原因是早期某条反馈文本里出现了一个特殊标记ticket_1234这种格式模型后来的注意力被这个标记吸引开始“脑补”出其实并不存在的关联规则。修复方案是两方面的。第一在任务循环里对进入上下文的文本做清洗——把原始反馈里的特殊标记统一替换为结构化占位符。第二在校验环节加入了“决策一致性检查”每隔固定步数抽取若干条已分类结果让校验模型检查是否有中途标准漂移有则回退到最近一个 checkpoint 重新执行。这两个改动让长任务的稳定性大幅提升。5.2 事故二无限循环与 token 燃烧有一个版本当某个工具返回空数据时agent 会陷入“查询 → 结果为空 → 换个条件查询 → 结果还是空”的循环。从日志看它甚至尝试了各种毫无意义的查询参数组合直到把 token 烧完。这个问题的根源在于空结果本身是一种有效结果但模型经常把“空”理解成“我没查对”于是试图再查。修复就是我前面提到的连续失败计数 路径标记。一旦某个动作连续失败超过 N 次系统会立刻标记“该路径已不可行”并明确告诉模型“不要再尝试同类查询请基于已有信息继续或向用户请求更具体的方向”。这个修复本质上是剥夺了 agent 的“无限重试权”——在真实组织里一个员工反复用同一种方法尝试 20 次失败还不换思路早该被提醒了。5.3 事故三模型生成的“幻觉分类理由”如何被拦截更隐蔽的问题是模型对某些模糊反馈的分类本身没错但它生成的理由是事后编造的。比如某条反馈说“发货太慢了”模型把它归为“物流问题”并写了一句“用户语气强烈暗示对配送时间极其不满”。但实际上用户只说了五个字根本没有“语气强烈”。我加入了一个“理由可信度校验环节”让校验模型判断理由中是否含有超出输入文本内容的推测性陈述例如“暗示”“可能说明”“明显表示”这类词出现时会标记为“过度解读”要求重写。第一次修正后分类结果的理由质量明显更贴合原文——这对我特别重要因为在这个项目的业务场景里分类理由是要直接呈现给运营团队的可信度不够会让整个系统被打上“不靠谱”的标签。5.4 兜底设计人工介入的入口到底放在哪里即便做了这么多防护我依然保留了人工介入的入口。关键是怎么设计这个入口让它既不影响效率又能真正兜住底。我的设计是三级兜底第一级风险操作前强制审批前面提到的规则第二级连续失败或低置信度时自动暂停转到人工队列第三级任务完成后生成“决策摘要”允许人工一键回滚到任意 checkpoint很多人觉得加人工入口是“不够智能”的表现但我的观点正好相反在当前的模型能力下敢于主动请求人工介入的系统才是真正可投入生产的系统。那种硬撑到底的 agent 也许在 demo 里更惊艳但上线一个月后就会在各种极端数据上把团队坑到怀疑人生。对于模型的置信度我用了两个来源的交叉验证一是模型在返回结果时附带的confidence字段——虽然这数字有时虚高但作为参考有用二是由一个独立小模型对“分类结果与原始文本的匹配度”打分。两者都低于阈值时才触发人工介入。这个双校验比单纯依赖单一模型的自信度靠谱不少。6. 评估方式如何知道你的 Agent 今天变好了还是变坏了这也是一个常被忽略的问题。最终要交付一个真正可用的系统你不能只在开发时测几个用例就宣布完成。你需要一个可重复、自动化的评估机制否则后续每次改个 prompt 都只能靠“感觉”判断有没有变好。6.1 我搭建的“回归测试集”与指标定义我建了一个包含 50 个任务样本的评估集30 个是历史跑成功过的精选任务20 个是高频边界情况如空数据、极端长文本、模糊分类、跨步骤依赖等。每次我对系统做任何改动——改 prompt、改工具描述、改决策逻辑——都会先跑一遍这个评估集对比改动前后的指标。用的核心指标有四个任务完成率跑完整个任务循环且交付物“可用”的比例平均决策步数完成同一批任务需要的步骤总数越少代表效率越高人工介入率需要触发审批或求助的任务占比越低代表自主性越强工具调用准确率工具的调用参数是否符合规范、是否选对了工具这个评估体系的建设成本投入在早期是有点烦的但后期改系统的时候真香——至少有客观数据说话而不是开发群里互相争“我觉得新版更聪明”这种毫无意义的话。6.2 长尾问题的持续再生机制评估集固定下来还有一个好处当线上跑出某个新的问题样本我会立刻把它追加进评估集。以后任何一个改动如果让这个样本重新劣化测试马上能抓到回归。这个过程我开玩笑叫“给 agent 建病历”——每一个曾经犯过的错都被记录在案随时可以被复查。长期下来整个系统的稳定性是螺旋上升的而不是靠灵光一闪。7. 给新人的建议从零搭建agency-agents的最小路径文章最后给打算自己动手做类似项目的人一条最稳妥的路径。当年我要是有这份清单能少走不少弯路。7.1 第一阶段不要追求“全自主”先跑通一个受限闭环很多人第一次做 agent 就想要一个完全自主的东西结果半年过去了还在调 prompt。我的建议是缩小范围先选一个特别窄的任务例如“把指定邮箱的附件按规则重命名并归档”跑通我刚才说的 Perceive → Decide → Act → Verify 闭环。这个阶段你只需要一个模型、两个工具、一个简单的校验逻辑。目的不是解决问题而是理解“模型自主决策时会出现哪些不可预料的边界”。7.2 第二阶段把失败案例结构化形成你的“坑位清单”第一阶段必然会翻车。每翻一次就往你的分类清单里记一笔这是哪类问题——是工具描述不清、是上下文污染、是模型幻觉、是循环重试、还是状态丢失。积累 20-30 个案例后你的系统设计会出现非常清晰的改进方向。这个阶段的核心是记录和归纳不要急着修。7.3 第三阶段加入自主能力但永远保留“安全阀”当你对翻车案例的类型有了充分认识就可以开始提升自主度——增加工具数量、增加决策自由度、考虑多 agent 协作。但每一层自主度的增加都必须同步设计对应的“安全阀”。例如增加一个新的“写操作”工具就同时增加这个工具的风险审批规则增加一个专员 agent就需要明确主管对它的监督机制。每一次放权都要有对应的刹车机制。7.4 终极提醒Agent 项目的隐藏成本全部集中在“评估”我不想展开太多口号式的鸡汤只说一个我反复感受到的事实agent 系统的研发成本和普通后端系统完全不是一个量级。普通后端你写完代码测试完就能上线agent 系统你要持续维护的是模型的决策质量——这本质上是数据标注、评估集建设、回归测试和线上监控的持续投入。要把这个成本算进预算里否则项目很容易在“演示很好但不敢上线”的尴尬阶段徘徊不前。说起最终的体会我在这个项目里最大的转变是明白了“能自主”和“该自主”是两回事。一个成熟的 agent 系统不一定要做很多勇敢的决策而是要知道哪些决策它可以自主、哪些决策必须请示。这个边界划得越清晰系统反而越强大。把这个边界设计好比让模型变聪明重要得多。如果你正准备上手做一个类似的项目建议把上面说的“风险动作规则”“校验模型分离”“结构化通信协议”这三件事先落实在代码里——它们花不了太多时间但会帮你挡掉后续绝大多数返工。欢迎在评论区聊聊你遇到的翻车案例尤其是那些反复出现同一类错误的说不定能给其他正在做 agent 的人省下一周时间。
