Agent架构新范式：从功能堆叠到大脑+技能+护栏

1. 从功能堆叠到能力编排软件架构正在经历什么过去十几年我们做软件架构的思路基本没变过先画模块图再定义接口然后一层层实现业务逻辑。一个电商系统就是商品模块、订单模块、支付模块、库存模块拼在一起一个CRM就是客户管理、销售漏斗、报表统计堆起来。这套思路的本质是功能堆叠——把需求拆成功能点再把功能点翻译成代码模块。但这套玩法正在被一种新的范式冲击。通用Agent的出现让软件这个概念本身发生了位移。以前我们关心的是这个系统有哪些功能现在越来越多人开始问这个系统能完成哪些任务功能和任务听起来差不多实际上是两个维度的东西。功能是静态的、预设的、边界清晰的任务是动态的、组合的、边界模糊的。我举个具体的例子你就明白了。传统的报销审批系统你会设计一个提交报销单的功能字段包括金额、事由、发票附件然后走审批流。但如果换成Agent驱动的系统用户可能直接说帮我把上周出差的费用报了Agent需要自己去理解上周出差去了哪、花了什么钱、哪些票据在邮箱里、公司报销标准是什么、该走哪个审批人。这里面没有一个是传统意义上的功能全是能力的动态编排。这就是标题里说的大脑技能护栏的由来。大脑负责理解意图和规划路径技能负责执行具体操作护栏负责约束边界和保证安全。传统软件架构里的那些模块在这个新范式下会被重新归类有些变成了技能有些变成了护栏有些直接被大脑的推理能力替代了。我并不是说传统架构会一夜之间消失。存量系统还会跑很多年但增量系统的设计思路已经在变了。如果你现在还在用画模块图的方式设计新系统可能需要停下来想一想这个需求真的需要一个独立模块吗还是说它其实只是Agent的一个技能2. 拆解大脑技能护栏每个部分到底在干什么2.1 大脑不是模型本身而是推理与规划层很多人一听到大脑第一反应就是哦大模型。这个理解太窄了。大模型只是大脑的算力基础真正的大脑是推理与规划层——它决定了一件事该怎么做、分几步做、每步用什么技能、遇到异常怎么调整。我见过不少团队接了个大模型API就觉得自己有了大脑。结果一跑起来发现模型确实能回答问题但没法完成多步骤任务。为什么因为缺了规划层。规划层要做的事情包括任务分解、依赖分析、执行顺序编排、中间结果校验、失败重试策略。这些东西不是模型自带的是需要你在架构里显式设计的。打个比方大模型像一个很聪明的顾问你问他什么他都能答。但顾问不等于项目经理。项目经理要把一个大目标拆成可执行的任务清单分配给合适的人跟踪进度处理突发状况。大脑里的规划层就是这个项目经理的角色。实际落地时规划层通常包含几个关键组件意图识别、任务分解器、执行调度器、状态管理器。意图识别负责把用户的自然语言转成结构化目标任务分解器把目标拆成子任务执行调度器决定子任务的执行顺序和并行策略状态管理器跟踪整个执行过程的状态。这四个组件配合起来才构成一个完整的大脑。2.2 技能从写死功能到注册能力技能这个概念是相对于传统功能模块提出的。传统功能模块是写死的你调用createOrder()它就创建订单逻辑固定。技能则是可注册、可发现、可组合的能力单元。我自己的做法是把每个技能定义成一个标准化的描述技能名称、输入参数、输出格式、适用场景、约束条件。Agent在执行任务时会根据当前上下文去匹配可用的技能。这就像给一个新人发了一本能力手册他需要什么就翻什么。技能和传统API的区别在于粒度。传统API往往粒度很细一个业务操作要调十几个接口。技能则倾向于任务级粒度——一个技能对应一个完整的子任务。比如发送邮件是一个技能查询订单状态是一个技能生成报表是一个技能。Agent不需要知道发送邮件底层用的是哪个邮件服务它只需要知道有这个技能可用。这里有个容易踩的坑技能粒度太细Agent的规划负担会很重粒度太粗灵活性又不够。我的经验是技能粒度应该对齐一个人类员工能独立完成的最小任务单元。如果一个任务需要人来回切换三个系统才能完成那它就不适合做成一个技能应该拆开。2.3 护栏不是限制而是可信边界护栏这个词容易被误解成限制AI不要乱来。这个理解只对了一半。护栏的真正作用是建立可信边界——让Agent的行为在可预期、可审计、可回滚的范围内。护栏至少包含三层输入护栏、执行护栏、输出护栏。输入护栏检查用户请求是否在允许范围内执行护栏约束Agent能调用哪些技能、能访问哪些数据、能执行哪些操作输出护栏校验结果是否符合规范、是否包含敏感信息、是否需要人工确认。我特别想强调执行护栏里的权限收敛。传统系统里权限是绑在用户身上的。但在Agent系统里权限应该绑在任务上下文上。同一个用户在完成不同任务时Agent能访问的数据范围应该是不同的。这需要你在护栏层做动态权限计算而不是简单复用传统的RBAC模型。还有一个容易被忽略的点护栏必须是可观测的。也就是说Agent每一次被护栏拦截都要有日志、有原因、有上下文。否则出了问题你根本不知道是模型判断错了还是护栏太严了。我在实际项目里会要求护栏拦截日志至少包含拦截时间、任务ID、触发规则、请求内容摘要、拦截后的处理动作。3. 为什么传统模块化架构在这个范式下会失效3.1 模块边界和任务边界不重合传统架构的核心假设是业务可以拆成相对独立的模块模块之间通过明确定义的接口通信。这个假设在功能固定的场景下成立但在任务驱动的场景下经常失效。原因很简单任务会跨越多个模块。用户说帮我处理一下这个客户的退款这个任务可能涉及订单模块、支付模块、客服模块、财务模块。在传统架构里你需要写一个退款编排服务来协调这些模块。但每来一个新任务你就要写一个新的编排服务。任务越多编排层越臃肿。Agent架构下编排不再需要你手写。大脑的规划层会根据任务动态决定调用哪些技能。这意味着你不需要为每个任务写一个编排服务你只需要把技能注册好剩下的交给规划层。这是架构层面的根本性简化。3.2 状态管理从模块内变成任务内传统架构里状态是分散在各个模块里的。订单状态在订单模块支付状态在支付模块用户状态在用户模块。跨模块的状态一致性靠事务或者最终一致性方案来保证。但在Agent执行任务的过程中状态是围绕任务聚合的。一个任务从开始到结束中间产生的所有状态——当前执行到哪一步、上一步的结果是什么、下一步该做什么——都应该在一个地方管理。这个状态管理器不属于任何业务模块它属于大脑。这个变化带来的影响很大。你不能再假设状态存在某个模块的数据库里你需要一个独立的任务状态存储而且要支持快速读写、支持回滚、支持审计。我见过一些团队试图用传统的工作流引擎来干这个事结果发现工作流引擎的状态模型太刚性没法适应Agent的动态规划。3.3 接口设计从人调用变成Agent调用传统API是给人写的或者给前端代码写的。所以接口设计讲究语义清晰、参数明确、错误码规范。但Agent调用技能时它需要的是自描述的能力——这个技能能干什么、需要什么输入、会返回什么、有什么限制。这意味着技能接口需要额外的元数据层。我通常会在技能注册时要求填写技能描述自然语言、输入schema、输出schema、前置条件、后置效果、失败模式。这些元数据不是给人看的是给Agent的规划层看的。规划层根据这些元数据来判断某个技能是否适用于当前任务。这个变化对后端开发的影响是深远的。以前你写完接口就完了现在你还要写一份技能说明书。而且这份说明书的质量直接决定了Agent能不能正确使用这个技能。4. 落地这套架构时我踩过的五个坑4.1 坑一把大脑做成了万能胶刚开始做的时候我恨不得把所有逻辑都塞给大脑觉得模型够聪明什么都能推理出来。结果就是响应慢、成本高、不稳定。模型每次都要从头推理没有复用没有缓存稍微复杂一点的任务就超时。后来我调整了策略大脑只做规划不做执行。具体来说大脑负责理解意图、分解任务、选择技能、处理异常。至于技能内部怎么实现大脑不关心。这样大脑的推理负担大幅降低响应速度和稳定性都上来了。这个坑的本质是把智能和执行混在一起了。正确的做法是分层——智能层做决策执行层做操作两层之间通过技能接口解耦。4.2 坑二技能注册没有版本管理技能是会迭代的。今天发送邮件技能只支持纯文本明天要支持附件后天要支持模板。如果没有版本管理Agent调用时就会出问题——它以为技能还是老版本传的参数对不上。我现在的做法是技能注册必须带版本号而且旧版本要保留一段时间。Agent在规划时会指定技能版本或者由调度器根据兼容性规则自动选择版本。同时技能描述里要写清楚版本差异方便排查问题。这个坑的教训是技能不是静态的它是一个会演进的接口。你需要像管理API版本一样管理技能版本。4.3 坑三护栏写得太死把正常任务也拦了护栏太松会出安全问题太紧会出效率问题。我一开始把护栏写得很严结果Agent稍微做点正常操作就被拦用户体验极差。后来我改成了分级护栏低风险操作直接放行中风险操作记录日志但放行高风险操作才拦截并要求确认。风险等级不是写死的而是根据任务上下文动态计算的。比如同样是删除数据删除草稿和删除已发布内容风险等级完全不同。这个坑的关键认知是护栏的目标不是零风险而是风险可控。绝对安全的系统等于不可用的系统。4.4 坑四没有做任务回滚出了问题只能手动修Agent执行多步骤任务时中间某一步失败是常态。如果没有回滚机制失败后系统会处于一个不一致的状态只能人工介入修复。我现在要求每个技能都要定义补偿操作。比如扣款技能的补偿是退款发送通知技能的补偿是发送更正通知。当任务执行失败时大脑会根据已完成步骤的补偿操作反向执行回滚。当然不是所有操作都能回滚那些不能回滚的技能要在注册时明确标注规划层会尽量避免在关键路径上使用它们。4.5 坑五低估了可观测性的重要性Agent系统比传统系统难调试得多。传统系统出问题你看日志、看调用链基本能定位。Agent系统出问题你看到的是任务失败了但为什么失败、哪一步失败、是规划错了还是技能执行错了很难一眼看出来。我后来强制要求每一次任务执行都要生成完整的执行轨迹包括规划结果、技能调用序列、每步的输入输出、护栏拦截记录、异常堆栈。这个轨迹要能可视化展示方便快速定位问题。没有这个Agent系统根本没法运维。5. 如果你现在要动手从哪开始5.1 先别急着换架构先做技能盘点如果你手上有一个存量系统不要一上来就推翻重做。先做一件事把现有功能盘点成技能清单。具体做法是列出系统所有对外提供的能力然后按任务级粒度重新归类。你会发现很多细粒度的接口可以合并成一个技能也有一些接口需要拆分。这个盘点过程本身就有价值。它会让你看清楚哪些能力是真正被使用的哪些是冗余的哪些能力经常被组合使用哪些是孤立的。这些信息对你后续设计技能注册表非常关键。5.2 从单一场景切入别贪大我见过一些团队一上来就想做一个通用Agent平台结果做了半年还在打地基。我的建议是选一个高频、边界清晰的场景先跑通。比如自动生成周报、智能客服工单分类、合同关键信息提取这种。选场景的标准有三个一是任务边界相对清晰不需要太多跨系统协调二是失败成本可控出错了不会造成严重后果三是有明确的成功标准能衡量效果。满足这三个条件的场景适合作为第一个落地试点。5.3 护栏和可观测性要同步建设很多人做Agent项目先把大脑和技能做出来护栏和可观测性放到最后。这是个危险的顺序。因为护栏和可观测性不是锦上添花它们是让系统可运维的前提。我的做法是大脑、技能、护栏、可观测性四者同步推进。哪怕第一版护栏很简单只有基本的输入校验和日志记录也要有。可观测性哪怕只是把执行轨迹打到日志文件里也要有。这些东西后期补的代价比一开始就做要大得多。5.4 技能注册表的设计要点技能注册表是整个架构的核心组件它的设计质量直接决定了系统的扩展性。我总结几个关键设计点设计点说明常见错误技能描述用自然语言描述技能用途供规划层匹配描述太技术化Agent看不懂输入输出Schema结构化定义参数和返回值Schema太宽松导致调用出错前置条件技能执行前必须满足的条件不写前置条件导致执行失败补偿操作技能失败时的回滚方式不定义补偿失败后无法恢复版本号技能迭代的版本标识无版本管理升级后调用错乱风险等级技能操作的风险评估风险等级写死不随上下文变化这张表里的每一项都是我在实际项目中踩过坑之后加上的。你可以直接拿去对照检查自己的设计。5.5 一个最小可用的架构参考如果你想要一个最小可用的起步架构我建议包含这几个部分意图解析层接收用户输入输出结构化任务描述规划器根据任务描述和技能注册表生成执行计划执行器按计划调用技能管理执行状态技能注册表存储所有技能的元数据护栏层在输入、执行、输出三个环节做校验轨迹记录器记录完整执行轨迹供调试和审计这个架构不复杂但五脏俱全。你可以先用它跑通一个简单场景然后再逐步扩展。记住架构是长出来的不是设计出来的。一开始不要追求完美先让它跑起来然后在迭代中完善。6. 这套范式对开发者的实际影响6.1 后端开发的重心在转移以前后端开发的核心工作是写业务逻辑接收请求、处理数据、返回结果。未来后端开发的重心会转向技能封装和护栏设计。业务逻辑本身会被Agent的规划能力替代一部分但技能的质量和护栏的严谨性会变得更重要。这意味着后端开发者需要具备一些新技能理解Agent的规划机制、会写技能描述、能设计合理的护栏规则。这些不是传统后端开发的必备技能但在新范式下会越来越重要。6.2 前端会变成任务界面而非功能界面传统前端是功能驱动的这个页面有这些按钮那个页面有那些表单。未来前端会更多地向任务界面演化用户描述一个目标界面展示Agent的执行过程和结果。这对前端开发者来说是个不小的转变。你不再需要为每个功能设计独立的交互流程而是需要设计一套通用的任务展示框架——能展示任务进度、中间结果、异常提示、人工确认请求。这套框架的复用性会很高但设计难度也不小。6.3 测试策略需要重构传统测试是功能测试给定输入验证输出。Agent系统的测试要复杂得多因为同样的输入Agent可能走不同的执行路径。你需要测试的是任务成功率和异常处理能力而不是单个功能的正确性。我现在的做法是建立任务测试集每个任务包含多个变体输入验证Agent能否在各种情况下完成任务。同时还要做护栏测试验证异常输入和越权操作能否被正确拦截。这套测试策略和传统测试差别很大需要重新积累经验。7. 关于所有软件只剩大脑技能护栏这个判断这个判断方向是对的但只剩这个词可能过于绝对。我的看法是不是所有软件都会变成Agent但所有软件都会受到Agent架构的影响。一些简单的工具类软件可能永远不需要Agent一个函数就能搞定的事没必要上大脑。但复杂的企业软件、协作软件、决策支持软件大概率会向这个方向演化。因为用户要的不是功能是结果。Agent架构能更好地交付结果。另外大脑技能护栏是一个逻辑分层不是物理部署架构。实际落地时这三层可能跑在同一个进程里也可能分散在多个服务中。关键是逻辑上要分清职责而不是纠结于物理形态。我在实际项目里的体会是这套架构最大的价值不是技术上的先进而是它让软件更贴近人的工作方式。人工作时就是先理解任务、再规划步骤、然后调用各种工具、过程中遵守规则。Agent架构本质上是在模仿这个过程。当软件的工作方式和人的工作方式对齐时很多以前很难解决的问题——比如跨系统协作、动态流程、异常处理——会变得自然很多。最后分享一个小技巧如果你刚开始接触这套架构不要从技术入手从观察人的工作流程入手。找一个你熟悉的业务场景观察一个熟练员工是怎么完成任务的他先做什么、后做什么、用什么工具、遇到问题怎么处理、有什么规则约束。把这个过程画出来你会发现它天然就是大脑技能护栏的结构。技术实现只是把这个结构翻译成代码而已。