你可能听过不少人把“Agent”挂在嘴边也见过各种“智能体平台”的演示视频但真正做落地的人都会碰到同一个灵魂拷问我写的这个东西到底是一个Agent还是一个带提示词的if-else这个问题的答案基本就藏在标题这几个词里agency-agents。在AI工程领域agency指的是智能体在任务执行过程中拥有的自主决策空间直白说就是“它能自己做主到什么程度”。一个只有“用户问一句、模型答一句、调一次工具”的流程其实没有多少agency一个能自己拆解目标、规划步骤、调用工具、根据结果修正路线的系统才配叫真正的agent。这篇文章不讲虚的。我会从agency的定义讲起把智能体系统的核心架构、最小可运行实现、多智能体协作的踩坑点、以及安全边界的设计都过一遍。内容主要面向已经会调模型接口、想从“写脚本”跨到“做Agent”的开发者也适合正在设计智能体产品的产品经理和技术负责人参考。我会尽量用做过项目的人才会讲的细节把每一步“为什么这么设计”说清楚。1. “Agency-Agents”到底是什么意思1.1 它不等于“能调API的脚本”很多团队说在做Agent实际代码长这样用户输入先走一层意图分类分到“查天气”就调天气API分到“订机票”就调订票API每个分支写死一套参数拼接。这套东西跑起来很稳但它不是Agent只是一个“智能路由脚本”。真正的agency-agents系统核心在于让模型在运行时决定调用哪条路径而不是在编译期就定死路径。我举个具体例子。假设任务是“帮我整理本周项目周报”。一个固定脚本会做读取某个固定表格套一个固定模板生成Word。如果数据缺失它就报错。而一个有agency的智能体会这么做先理解“整理周报”到底需要哪些信息主动检查数据源发现某个同事的数据没提交判断这是阻塞问题于是决定先发一条提醒消息或者标记为“待补充”根据已有数据生成草稿并在报告中注明缺失项最后请用户确认是否发送。注意第2、3步系统在运行过程中自己决定了一个不在初始指令里的动作这就是agency的体现。脚本是“模拟自主”系统必须有“决策—行动—观察—再决策”的闭环。所以在设计阶段第一个要问的问题不是“我用哪个框架”而是“我的业务允许多大自主空间”。如果你是做一个客服工单自动分类系统自主空间可以很小如果你是做一个帮你调研、写稿、整理资料的私人助理自主空间必须很大否则它会笨到每个小分支都要问你体验极其糟糕。1.2 一个Agent的“自主权限”应该有多大这里就得把agency拆成三个可度量的维度决策范围、执行权限、自我纠错能力。决策范围指Agent能在多少个节点上做选择。最小范围是只能选择调用哪一段提示词中等范围是能自己拆分子任务最大范围是能自己定义新工具并纳入后续计划。执行权限更直接它决定了Agent能不能写文件、发消息、改数据库、花预算。自我纠错能力则是当第一次执行结果不符合预期时系统能否自己诊断原因并重试。有三个项目我实际参与过的经验第一决策范围可以大但执行权限必须从小处开始。第二自我纠错能力一定要配“最大重试次数”否则大模型会陷入非常执拗的循环反复用同一个错误方法尝试。第三用户确认点不能放在“动作之后”要放在“动作之前”这件事我在后面实操部分会展开。另一个很重要的点是agent的自主权和可控性是正交的不是对立的。你可以让Agent拥有很大的探索范围同时在关键动作上设置“闸门”。这两件事完全可以同时做到前提是架构上要把决策逻辑和权限校验分开不要让权限校验散落在各个步骤里否则后期加安全策略会非常痛苦。2. 如何把“自主性”落进系统设计2.1 从“提示词编排”到“规划器—执行器”的转变我第一次认真做智能体当时的思路还是“每个任务写一个提示词模板然后按顺序跑”。后来遇到一个真实需求用户用自然语言描述“把这几份报表合并并找出每个月异常增长的指标”。我一开始写了五个串行步骤结果用户换了一种说法流程就全乱了。真正让我转过弯来的是换成“规划器—执行器—评估器”的结构。这个结构的核心思路规划器负责把用户目标转成一个可执行步骤列表执行器负责跑具体动作评估器负责检查结果是否达到预期。三个角色可以都是大模型也可以是不同模型甚至可以其中两个角色用规则实现。它最大的好处是把“想”和“做”分开了规划变了执行逻辑可以复用执行出错评估器可以定位问题在哪一步。我习惯给这个结构加一个“工作区”也就是存储中间产物的空间。比如处理报表的任务规划器说“先读取文件A和B”执行器就把读取到的表格写入工作区下一步“合并文件”就能直接在工作区上操作。没有工作区的Agent每一步都要重新加载上下文很快会碰到长上下文瓶颈。这里有个关键设计规划器生成的不只是步骤列表还要包含每个步骤的输入依赖、输出预期、是否允许失败。这是很多新手忽略的地方。没有依赖关系执行器就不知道下一步该拿什么作为输入没有“是否允许失败”标记Agent面对一个非关键步骤失败了会不知所措要么整个中断要么硬着头皮继续结果一步错步步错。2.2 给Agent装“记忆”和“工具”时要注意什么谈到agents系统记忆和工具是绕不开的两块。先说记忆。我推荐分三层短期记忆当前任务上下文比如用户需求、步骤列表、中间结果一般存在工作区里长期记忆跨任务保留的事实比如用户的偏好、历史项目的数据口径程序记忆写进系统里的规则和技能比如“导出Excel时列宽不小于12”。很多人在短期记忆上疯狂做大窗口却忽略长期记忆的设计。实际上真正拉低智能体效果的往往是长期记忆的检索噪声——你把无关历史全部塞进上下文模型反而不知道现在该关注什么。正确做法是给长期记忆打标签比如“客户A的报表口径同比按自然年计算”等任务涉及客户A时再注入。工具接入的点核心是工具描述要像API文档给陌生人看。我见过最普遍的问题是工具描述写得过于简短模型根本不知道什么时候该用这个工具。一个合格的工具Schema至少包含四部分工具名称命名要带动词和对象比如send_reminder_to_member功能描述说清楚“这个工具能做什么、不能做什么”参数列表每个参数要注明类型、必选否、取值枚举返回结构告诉模型返回的数据长什么样尤其要说明失败时返回什么字段。你不要高估模型的工具选择能力。如果两个工具功能接近模型经常选错。所以工具数量控制在20个以内超过这个量就必须做“按域分组先选域再选工具”的二级路由。2.3 设计一个“安全终止”机制Agent的自主性再强也必须有终止机制这跟汽车马力再大也得有刹车是一个道理。我之前见过一个内部DemoAgent循环“查询数据—生成报告—发送报告”停不下来因为评估器永远认为报告不够好结果一晚上发了三十多封邮件把同事邮箱塞满了。这个事故之后我在所有智能体系统里都加了以下四道保险最大循环次数一个任务最多迭代多少次超过就强制结束并转人工动作熔断同一个动作连续执行N次没有进展直接触发暂停关键操作前置确认凡是涉及对外发送、写数据库、扣减余额的操作先向用户展示准备执行的动作等确认后再执行审计日志每一步的行动、输入、输出、耗时全部落盘。这四条里“动作熔断”最容易被忽略。大模型的自我纠错经常会变成“换了种说法干同一件事”。比如它连续三次调用同一个查询接口只是把日期格式换了其实根因是数据库里根本没有那天的数据。没有熔断机制它就能这样空转到天荒地老。3. 实操搭一个带Agency的最小智能体3.1 系统角色定义与最小闭环理论说了不少这块直接上手。我建议不要一上来就上重型框架先用手写代码把核心闭环跑通。你需要三个组件Agent大脑也就是大模型的调用封装负责规划、决策、反思工具层包括函数注册、参数解析、结果返回运行循环控制“规划—执行—评估”的循环和终止条件。我用一个很简化的Python伪代码来演示核心逻辑。完整代码不好贴但关键结构足以表达设计思路def run_agent(task, tools, max_steps8, confirm_gatesNone): workspace {} history [] for step in range(max_steps): # 1. 大脑决策根据任务、历史、工具描述决定下一步动作 action model_choose_action(task, history, tools, workspace) # 2. 检查是否应该结束 if action[type] finish: return build_final_answer(action, workspace) # 3. 权限判断与用户确认 if action[type] in (send_message, write_db, pay): if not user_confirm(action): history.append({role: system, content: 用户拒绝了该操作请更换方案}) continue # 4. 执行工具调用 result execute_tool(action, tools, workspace) # 5. 记录历史 history.append(result) workspace.update(result.get(outputs, {})) # 6. 简单熔断连续相同动作超过3次则中断 if repeated_action(history, threshold3): raise NeedHumanIntervention(检测到重复动作转入人工处理) raise MaxStepsExceeded(超过最大步数任务终止)这段代码最核心的设计是第3步的确认闸门。你可以通过confirm_gates配置哪些动作需要用户确认。在开发初期我建议宁可多确认也不要少确认等算法稳定了再逐步放开。model_choose_action是灵魂。它的提示词我会写成类似这样你要根据当前任务目标、工具列表、已有中间结果输出一个JSON动作动作类型只有call_tool和finish。如果你需要call_tool必须说明工具名、参数和“为什么选择这个工具”。加“为什么选择这个工具”这句话不是为了给人类看而是强迫模型用思维链推理一遍能明显降低选错工具的概率。3.2 用最小案例跑一个任务假设任务是这样“帮我把项目列表文件中描述的所有未完成事项整理成一份周报草稿缺失负责人信息的标为待确认。”我组织了三个工具read_project_file(path)读取本地项目文件extract_tasks(content)提取任务列表与状态write_draft(text)将草稿写入本地文档。第一次跑模型通常的决策路径是先读文件 → 提取任务 → 检查负责人是否缺失 → 生成草稿 → finish。这个路径看起来没问题但真实运行中我遇到过一个有趣情况模型读完文件后发现文件里根本没有“负责人”字段于是它自己决定去另一个文档里搜索负责人信息。这个动作没有出现在初始计划里但它合理因为它发现当前信息不足后才自主发起的探索。这正是agency的价值。也有反面案例。另一个模型在生成草稿前先调用了一个get_current_time()工具然后生成了带日期标题的文档。这个动作也不算错但它占了一次调用步数。如果系统对调用步数没有限制这类“看似有用实则可有可无”的动作会越积越多最后把上下文塞满。所以我后来给工具列表加了一个“必要级别”字段规划器优先选择必要级别高的工具。3.3 结果评估与失败处理运行循环里的“评估”环节我用得很重。最简单的方式是把评估器也做成一次模型调用给模型看当前任务、执行历史、以及最新的动作结果让模型判断“任务是否完成、是否需要重试、下一步该做什么”。这个评估器虽然也是模型但它和规划器的区别是规划器面向未来评估器面向历史。两者用不同的系统提示词才能避免角色混淆。一个很有效的经验是评估器不要只输出“成功/失败”必须输出失败原因和修复建议。比如它应该说“失败原因是没有读取到最新版本的项目文件建议先调用get_latest_version再重试”而不是简单一句“失败”。带修复建议的失败才真正能让Agent形成自我纠错闭环。4. 多智能体协作与“失控”预防4.1 用不同“Agent角色”组成虚拟团队单Agent遇到复杂任务容易上下文爆炸、历史太长、决策质量下降。我的解法是拆成多Agent协作。这不是赶时髦是工程上必要的手段。比如一个报告生成任务我会拆成“项目经理Agent 数据分析Agent 撰写Agent 质检Agent”。项目经理负责拆解任务和分配子任务数据分析Agent负责查询和计算撰写Agent负责把结果写成报告质检Agent负责检查是否遗漏需求。这个模式里每个Agent的上下文只装自己那部分内容不会被全局历史淹没。比如数据分析Agent不需要知道撰写Agent用了什么语气它的世界就是“拿到需求查数据返回结构化结果”。责任边界清晰之后代码维护和问题定位都轻松很多。但是多Agent最大的代价是通信开销。如果两个Agent来回传大段文本延迟和token成本都会飙升。所以协作消息建议用结构化摘要传递而不是传完整文本。比如数据分析Agent只回传统计口径、结论摘要、异常说明不要回传原始数据表。等撰写Agent需要细节时再让它去读工作区的具体文件。4.2 共识机制为什么需要“确认点”多Agent协作中“确认点”是容易借鉴真实项目管理的方法关键节点必须由指定角色审核。比如分析Agent算出某指标异常不能直接写进最终报告必须由项目经理Agent复核一次确认口径没有搞错。这里本质上是加了一个角色冗余用两次独立判断减少幻觉传导。我踩过的坑是多Agent之间过于礼貌。A Agent发现数据有点怪通常会写“可能有问题”而B Agent看到“可能”两个字往往选择忽略继续往下走。所以我的系统提示词里明确要求“当发现数据异常时必须使用【阻塞】标记禁止使用不确定措辞。”这样质检Agent才能把它当作硬阻断而不是软提醒。4.3 协作冲突与仲裁多个Agent意见不一致时谁说了算我的做法是分两层如果冲突涉及事实问题比如数据计算不一致由仲裁Agent重新计算或者直接调用权威数据源如果涉及主观判断比如“这个报告段落要不要保留”则由用户决定Agent只负责展示两种意见的利弊。有些团队会把仲裁权交给“级别最高”的Agent比如项目经理Agent。但这有个问题项目经理Agent通常会倾向于“推进流程”为了完成任务而忽略细节风险。这就是“效率优先”和“质量优先”的冲突。我的经验是仲裁权应该交给与你当前业务核心目标最一致的角色。你是要效率就把仲裁权给进度管理Agent你是要准确性就把仲裁权给质检Agent而不是机械地按层级来。4.4 可观测性设计多Agent系统里最怕黑盒。排查问题的时候你根本不知道是哪一步决策错了。所以每个Agent的输入输出都要记录而且要记录“决策理由”。我的做法是要求模型在每个动作里附带一个reasoning字段简单解释为什么这么做。虽然模型可能撒谎但这个字段依然是排查问题的第一线索。日志级别也要区分。DEBUG级记录模型每次输入的完整上下文INFO级记录动作与工具返回值WARN级记录重试和降级ERROR级记录熔断和转人工。如果是生产环境我强烈建议把上下文日志单独存不要和应用日志混在一起否则日志量能把存储打爆。5. 常见翻车场景与排查手册5.1 五大典型问题速查表这一节直接给结论都是我帮别人排查Agent系统时浓缩出来的高频问题。现象大概率原因定位手段解决办法Agent反复调用同一个工具却失败模型没有真正理解错误信息或工具返回结构不透明打开工具返回日志看模型拿到的错误原文优化工具返回的error字段明确给出下一步建议Agent经常跳过关键步骤规划器生成了不完整计划或评估器把关太松查看规划器输出和评估器结论在评估器提示词中强调“未完成禁止finish”并加上缺失项检查上下文被中间结果塞爆工作区设计缺失模型每一步都把全文塞进历史检查历史消息长度引入工作区只把摘要和引用路径放入历史多Agent互相踢皮球角色边界不清晰指令含糊查看每个Agent的输入是否偏离职责重写系统提示词明确“你只负责XX其余必须转交”用户确认太频繁体验差确认闸门设置过于保守统计确认动作触发日志按动作类型和风险等级分级放开低风险动作5.2 三个容易忽略的细节坑第一个坑是工具返回结果太长。你的分析Agent调用某个查询接口返回了50行数据本意是好的但模型会把50行数据完整读进去再要调用下一个工具时上下文已经被一堆数值占满。后来我在工具层做了一个“返回压缩”逻辑超过若干行就自动做摘要模型需要细节再去读原始文件。第二个坑是普通文本日志掩盖了JSON解析错误。很多Agent返回JSON格式哪怕一个引号不对整个动作就解析失败。你排查问题时看到的是“JSON解析失败”但不一定看到原始模型输出。所以日志里一定要同时记录“模型原始输出”和“解析后的动作”两者对照才能定位是模型问题还是代码问题。第三个坑是模型把迭代当成了进步。我见过一个Agent在报告格式上反复修改了十几次每轮都觉得“更完善了”但用户只要求一份简单草稿。这说明评估器缺少一个“目标是否已满足”的硬性标准。我的修正办法是在评估器提示词里加上如果当前结果已经可以满足用户的核心需求禁止为次要细节继续迭代。5.3 一个低成本测试自主性的实验方法不少朋友问我怎么快速判断自己搭的系统到底有没有真正的agency我推荐一个“黑盒测试法”本地跑一下观察系统的行为模式。第一步设计一个需要多步决策的任务但要给一个模糊的约束比如“在做这个任务时注意不要使用内部测试环境的接口”。第二步把系统中某个核心工具故意置为失败观察系统是直接报错还是尝试替代方案。第三步在任务进行到一半时通过另一个通道告诉系统“需求变了比如原来要Excel现在要PDF”看它能否调整后续计划。这三步跑下来你基本就能判断系统的“自主性水平”它只会报错、不会绕过说明agency还很弱它能换工具完成但不能处理需求变更说明中规中矩它能接受新约束、调整计划、重排执行顺序说明架构已经具备真正的agency。我实际测试下来大多数“演示型Demo”都倒在第三步。原因是它们把任务流程固化得太硬缺乏一个随时可以重新规划的入口。而只要你把规划器放到循环里、并且每次决策前都重新评估当前状态和目标第三步很容易就能通过。最后再分享一个小技巧开发阶段可以故意把最大循环次数调小比如3次。这么做不是为了让系统完成复杂任务而是为了逼它“在有限次数内学会权衡”。次数一少模型就开始思考“哪些动作是必要的哪些是可有可无的”反而能逼出更高效的决策路径。等流程稳定了再慢慢把循环上限放开。这个反直觉的技巧在我自己的系统上实测效果很稳也让我真正理解了agency不是放得越开越好而是在约束里做最优选择的艺术。