上个月我参与某团队的一次架构评审对方技术负责人全程只问一个问题“为什么每次加新需求都像在拆炸弹”我把这个话题翻译成更直白的话不是代码写得差而是需求正在以自然语言的方式进来系统却还在按“点击路径”做响应。传统软件架构习惯把所有东西定义成固定流程状态机、接口、菜单、权限清单一切都在预期之内。通用Agent入场之后用户不再需要告诉系统“先点这里、再点那里”只要描述一个结果“我要季度经营分析报告”复杂动作就交给程序自己规划。这个变化看起来只在交互层实际动摇的是整套架构的根。我越来越确信一件事未来绝大多数软件会收敛成三层结构——大脑负责理解和规划技能负责调取真实世界的能力护栏负责守住边界。这篇文章把这三层拆开讲透顺便聊聊我亲眼目睹过的一些失败案例和修正思路。如果你正在做Agent相关项目或刚准备把老系统改造成“AI原生”这篇应该能帮你把注意力放在真正重要的地方。1. 传统软件架构在Agent面前先失守的三道防线1.1 确定性流程支撑不了开放式目标传统软件架构的底层假设是确定性。你收到一个请求能说清它对应哪个功能知道数据在哪些服务之间流转也能枚举异常分支。这套假设在过去的二十年里没有太大问题因为那时软件解决的是流程问题审批、结算、查询、打印路径都是可以预先画出来的。但通用Agent带来的需求是目标型问题目标型问题的边界是敞开的。用户不会逐一指定步骤而是直接丢一句“把这个月的异常订单整理出来发给财务”。这句话落到传统框架里没有任何一个现成的控制器可以接收也没有报表模板能直接匹配。过去我们依赖“人”把目标翻译成用例、接口和状态流转Agent想跳过这段人工翻译意味着软件自己得承担“从目标到步骤”的第一次转换。这部分工作在传统架构里没有位置只能另起炉灶。这也就是我所说的“大脑层”必须存在的原因。大脑层不是某一个大模型而是一个围绕模型构建的执行环境负责把模糊目标转成任务图再把任务图映射到可执行的技能调用。哪怕你现在的系统还是老单体只要你想接Agent这个规划层就不可能绕过去因为它是整套系统从“确定”走向“开放”的转接枢纽。1.2 交互入口从“人用界面”变成“意图接口”过去做B端系统交互全部收敛在页面上按钮、表格、弹窗既是交互方式也是业务规则的具象化。API虽然存在但更多服务的是前端。Agent没有前端的耐心它不会花十分钟理解你的菜单层级也不会看着高亮按钮猜测下一步操作。它需要的是一个“意图接口”输入一段目标描述输出一段能执行的技能序列。这会带来一个容易被忽略的结果页面不再是系统的唯一入口也不再是控制权的中心。你花三个月设计的导航和表单布局在Agent工作流里可能连背景板都算不上。真正重要的变成了系统对外暴露的语义描述也就是“技能描述文档”。用户如何表达目标、系统如何表达能力这才是新的交互契约。我见过一个企业内部系统把全部操作都塞进一个聊天框里页面几乎废弃。开发团队每天迭代的也不再是页面组件而是Agent技能的描述文本把“取订单”从“查询订单列表”改写成“按任意业务维度筛选订单并返回统计口径”就相当于重构了一个页面流程。这种变化会让传统前端团队不安但它确实是正在发生的趋势。1.3 静态权限清单兜不住动态授权权限模型值得单独拿出来说。RBAC解决的是“某角色可以碰某资源”的静态问题这在人主动操作时是够用的。可Agent的一次任务可能跨越五个系统携带的意图是复合的读销售数据、生成图表、发送邮件、安排会议。静态权限只能回答每个环节“能不能”回答不了整条链路的“应不应该”。这里举一个真实复现过的场景某团队给Agent开放了“读取订单”和“发送通知”两个接口分开看每个权限都很正常。但Agent在某个目标驱动下自发组合了这两个动作把一批未确认的订单提醒发给了外部联系人。单个接口都合规组合起来却绕过了业务边界。传统系统没有这个层级的控制因为传统用户不会故意把两个无关接口串成一个越权链路而Agent会而且会非常自然。所以Agent架构必须引入“意图级授权”判断一次任务整体是否被允许而不是只校验单点参数。这个判断逻辑放哪里、怎么做审计、谁有最终裁决权就构成了护栏层的核心。很多团队把精力放在模型选型和提示词优化上结果第一周就出了权限事故原因就是静态权限清单兜不住动态授权。这个问题不是管理流程能补的必须在架构层面预留位置。2. 大脑通用Agent的规划层如何改写传统流程编排器2.1 规划层的三层结构与可审计任务图很多人以为给系统接一个会思考的模型就等于有大脑了我理解不是这样。大脑应该是一个围绕模型搭建的执行环境模型是内核但真正运行起来需要三层配合目标解析、策略生成、执行调度。目标解析层把用户模糊的自然语言转成一个结构化的任务描述包含业务上下文、预期输出和限制条件。策略生成层决定达成目标需要哪些技能、以什么顺序调用、遇到失败时走什么备选路径。执行调度层负责真正调用技能、收集结果、做上下文汇总。三层可以全部由同一个模型驱动也可以混入规则和人工兜底但关键是必须产出可审计的轨迹。简化来看一个规划结果大致长成下面这样{ plan_id: plan_8f2a, goal: 生成季度经营分析报告, steps: [ { skill: query_metrics, reason: 先取数才能分析, params: {指标: 收入, 时间: 本季度} }, { skill: detect_anomaly, inputs: [query_metrics.result], when: 数据存在明显波动 }, { skill: create_report, params: {格式: PPT, 页数: 10以内} }, { skill: send_report, params: {收件人: 财务负责人}, guard: 需要人工确认 } ] }如果你设计过传统工作流引擎会觉得这个结构和流程编排很像。区别在于传统流程是写死的而这里的规划图每次会话都可能不同。执行过程中的分支决策由模型根据上下文实时决定。你必须接受这种不确定性同时用工程手段把不确定性关进笼子里而不是祈祷模型每次都保持理智。2.2 上下文管理决定Agent的“记忆质量”大脑层最常翻车的不是模型选型而是上下文管理。我见过一种配置把整个项目的文档、工单、聊天记录全部塞进上下文表面上模型“什么都懂”实则每次技能调用都因为无关信息过多而飘忽不定经常出现参数幻觉。正确做法是把上下文当成一个任务工作台。每个Agent会话分配一个独立工作区里面只放四类东西当前目标、必要的历史决策、可用的技能清单、禁止操作清单。判断一条信息要不要放进去标准不是“有没有用”而是“当前这个目标是否必须用它”。与目标无关的内容一律不进上下文避免干扰。关键动作完成后还应该对历史做摘要归档把冗长的对话压缩成决策记录这就是“记忆压缩”。这样做有两个直接收益第一模型在长任务里不容易丢信息第二后续审计可以还原当时为什么做了某个选择。你可能会觉得这层工作是模型层的但实际落地时它需要向量存储、会话缓存、事件总线一揽子基础设施。一个成熟的大脑层复杂度不亚于当初拆微服务时搭建的那套治理体系。2.3 最容易被忽略的坑把提示词当成全部架构这部分我想说得直白一点因为太多团队起的第一个念头就是跳过架构靠一个长提示词hold住局面。他们写一个包含“你必须严谨、安全、一步步思考、不要做出格操作”的系统提示词然后就把Agent上线。常规任务确实没什么问题但边界情况会暴露真相。我做过一次失败的验证把“禁止删除用户”直接写进提示词测试中只要换一种表达方式模型就会把删除操作当成清理临时数据来执行。提示词只能描述策略倾向它没有能力承载事务一致性、权限判定和审计日志。凡是不能被审计、不能被强制的规则都不应该只放在提示词里。后来我改成把不可变约束下沉到技能层和护栏层提示词里只保留目标拆解和表达风格。这样做的逻辑很简单提示词可以被对话内容影响而引擎层代码和配置不行。模型可以理解规则但只有系统能强制执行规则。记住这句话能帮你避开一大批“AI事故”。3. 技能老系统以“能力单元”的形式继续活3.1 技能接口与传统API的根本差异描述先于实现未来不存在“传统系统被淘汰”这种绝对概念只存在“系统还能对外提供哪些技能”。技能接口和传统API表面长得很像都是在暴露操作但它们的契约模型不一样。传统API关心路径、方法、参数类型、返回码Agent技能接口必须额外交代业务意图。比如一个传统接口是POST /order/create参数是product_id和count。技能接口还需要告诉模型它的作用是创建订单会产生库存锁定和支付回调等副作用这是写操作调用前需要确认用户授权失败时该做什么补偿。模型不是靠记忆去调用接口的而是靠读取那段技能描述文本做决策。所以描述文档的优先级比接口代码还高。这里可以做一个直观对比维度传统API描述Agent技能描述核心内容路径、方法、参数、返回码目标意图、参数语义、副作用、风险等级服务对象前端开发者、第三方程序模型、Agent规划器错误处理错误码、异常信息前置条件、失败兜底、回滚建议权力边界隐含在服务端校验显式声明“需要审批”“不可逆”“只读”描述写得模糊模型就会造出不存在的参数或者错误地判断时序描述里写了副作用模型才不敢随意反复调用。所以在一个Agent项目里技能描述的编写和评审是比写接口实现更前置的工程活动。3.2 技能粒度怎么选技能粒度是另一个高频错误区。某个团队把整套系统的操作封装成一个技能取名execute_action参数就是method和payload。Agent确实方便了但安全团队几乎崩溃模型只需一句话就能执行系统里几乎所有操作。这种万能工具在实际运行中几乎一定会被组合出危险动作。反过来把技能拆得过细也有问题。模型要完成“创建订单并通知仓库”如果得调用七八个基础技能多一跳就多一次出错机会。判断粒度时可以遵循几个标准一个技能必须对应一个业务完整动作动作要能独立回收结果副作用能被明确描述参数控制在十个以内复杂动作拆成几步每一步都有明确的语义名。读数据、写数据、发通知、批准、驳回都应该单独建模。不同模块如果存在重复动作尽量收敛成同一个技能避免模型在相似能力之间瞎猜。我常用一个生活化类比技能是给Agent安排的下属而不是万能遥控器。你给下属分派任务要让他清楚职责、边界和汇报方式你给遥控器多加按钮只会让一个毛手毛脚的人把所有按键都按一遍。3.3 迁移路径先影子模式再接管真正改造老系统我的建议是别等Agent能力彻底成熟再动手。先把现有系统包一层“技能适配层”让老代码继续当发动机适配层当方向盘。迁移路径可以分成四步把对外服务按业务动作拆成技能清单哪怕暂时还没有Agent在调用也要先把描述文档写出来。优先接入三到五个高频、易错、强反馈的动作让Agent在影子模式下运行。影子模式的决策全部记录但不真正执行拿这些日志跑历史场景回归。准确率和稳定性达标后再灰度放开真实执行权限。这套迁移方式既保住了老系统的稳定又能让技能层逐步生长。不需要一开始就动核心模块但技能边界必须尽早定义。老系统会因为这套技能层而重新获得生命力它不仅为人类用户服务也为Agent提供可理解、可编排的能力。4. 护栏比功能更能决定Agent能不能上线的东西4.1 四层护栏模型我每次给团队做Agent架构建议都会先画一张四层护栏图因为太多项目只做了其中一两层上线之后才意识到漏洞。四层分别是第一层是身份层确认当前对话由哪个用户发起、Token归属谁、跨会话能否延续、是否能代表某个组织操作业务数据。第二层是权限层把用户的角色权限翻译成技能调用范围但要在技能编排链路上二次校验而不是让Agent拿着用户权限到处调用。第三层是频率层限制单位时间内的调用次数和资源消耗防止Agent在循环里“点火”也防止一个死循环打爆下游服务。第四层是后果层把操作分成只读、写、不可逆三个等级写操作默认进入审批不可逆操作必须二次确认。这四层缺一不可。很多团队只做了权限层结果Agent因循环调用把消息推送服务打到限流这其实不是模型问题是频率层缺失的典型症状。也有的团队只关注后果层把每个读操作都卡在审批里最后用户烦到弃用。四层是互相配合的系统而不是单点依赖。4.2 审批不是阻断是让时间慢下来提到审批业务负责人第一反应往往是“效率是不是要下降”。会下降但下降的是“盲目效率”而不是有效效率。在Agent的护栏体系中低风险动作自动执行中风险动作记录留痕高风险动作弹出确认卡。确认卡不要只显示一句“是否允许Agent发送邮件”要显示动作的前因后果当前目标是什么、即将调用哪些技能、涉及哪些数据、会写入什么结果。用户确认前可以点开查看完整的技能调用链。这样设计才叫可审计事后出了问题你才知道是哪个技能、哪段规划、哪次判断错了。审批本身也是Agent工作流中的一个节点完全可以做成一个技能。用户收到审批卡点允许或拒绝Agent根据结果继续或停下。真正难做的不是审批功能而是“什么级别需要审批”的动态规则。只读查询不要审批写操作要审批不可逆操作更要审批规则可以按业务模块配置但不能放任Agent自己决定哪些需要审批那是把裁判和运动员焊在一起。4.3 影子模式、灰度发布与技能开关完整的护栏还需要覆盖发布机制。对一个Agent功能最稳妥的路径是提示词和技能组合先跑离线评估集再进入影子模式观察再放5%流量试点最后全量。每一级都要看两个指标任务完成率和事故率。回滚机制不能只回到上一个模型版本还要能终止特定技能的使用。护栏层可以维护一个技能开关列表一旦发现Agent反复调用某个技能产生副作用运维直接下线该技能。Agent会自动改走兜底流程或请求人工介入。这个设计比依赖模型自己改错可靠得多因为阻断是人在兜底而不是让模型自我反省。我见过一个团队把“发送邮件”技能的开关交给值班人员深夜Agent误发了一封外部报告值班人员一键下线事故影响半径瞬间缩小。事后复盘时大家最庆幸的不是模型表现而是那个随时可切断的技能开关。5. 某内部系统的改造实录从老单体到「大脑技能护栏」5.1 改造前一个“能跑”但“难改”的老系统以某团队的内部对账系统为例它包含订单库、银行流水导入、异常匹配、邮件通知几个模块。老逻辑是用一个定时任务跑的每天凌晨对账异常结果直接发邮件给财务人员。这套系统能跑但改起来非常痛苦业务口径一变定时任务就要改代码财务总监想临时看某个渠道的差异IT排期要两周新人根本说不清那些异常规则是怎么沉淀下来的。团队决定接Agent需求很朴素让财务人员用自然语言查对账结果并允许Agent自动生成异常报告。他们一开始以为只是加一个聊天框真正动手才发现传统系统根本没有“意图入口”。定时任务只接受配置文件邮件逻辑写死在代码里异常判断规则和业务逻辑耦合在一起Agent想调用也无从下手。5.2 改造后的三层长什么样改造完成之后系统边界变得非常清晰层落地形态关键内容大脑任务规划服务负责语义识别、拆解查询目标、按规则生成技能调用序列技能对账查询、明细获取、差异汇总、邮件发送、审批创建每个技能带描述文档和副作用声明护栏规则引擎加审批台只读查询自动放行写操作进入审批发送邮件默认挂起上线后的效果超出预期但不是因为模型本身多聪明而是业务人员第一次可以在不等待IT的情况下向系统提问。过去要第二天才能看到的定时任务结果现在随时可以生成临时对账单财务总监问一个跨渠道差异Agent能自己取数、汇总、生成报告再走审批发出去。这个体验的变化才算得上“架构重心迁移”。5.3 上线一个月真正要改的不是模型是边界复盘时我们总结了几个值得记录的教训。第一个教训是对账口径不是技术问题但它藏在技能描述里。财务忽然要把“周日订单”归类到上周IT只改了技能描述文本就完成了配置变更。传统做法得改代码、发版、走流程Agent化之后描述文本变成了一种可配置业务规则。第二个教训是审批频率比预想高。最初我们把发送邮件设为中风险自动执行结果上线第三天就有一封错误的差异报告发给了所有人。后来把发送动作升级为高风险人工确认后才放行事故就再没出现过。第三个教训更重要Agent会组合出没人预料到的路线比如把查询技能一路连到邮件技能直接跳过汇总页面。如果护栏层没有记录技能调用链路的全量日志这种组合只会在事故复盘时才暴露。所以我一直坚持护栏必须记录每一步决策和参数而不只是最终结果。日志里的plan_id、技能名、参数摘要、返回值、异常信息至少保留半年以上这是排查组合类问题的唯一线索。6. 留给工程团队的长期功课6.1 把需求评审改成“护栏评审”以前评审一个需求讨论的是功能、交互、数据模型。现在要增加一套问题集合这个需求允许Agent做什么不允许做什么哪些动作需要人工确认失败时回退到什么状态会不会影响其他系统。传统需求文档写用户故事通常只写正向路径但Agent需求必须把边界写成显式规则。我参加某团队的一次需求会产品经理一口气写了三十条“不允许”当时大家觉得夸张可上线后恰恰是这些“不允许”救了整个项目。比如“不允许Agent把外部对账单直接合并进正式账本”“不允许在周五下班后批量发送催款邮件”“不允许自动删除历史记录”。这些规则看起来过分谨慎但对Agent来说没有明确禁止的行为它就当全部默认允许。6.2 沉淀评估集防止模型升级导致行为漂移另一件被严重低估的事是评估集。模型在升级、技能在改、提示词在调你今天验证通过的Agent行为可能换个底层模型就完全不一样。团队平时应该维护三个评估集历史真实请求集、攻击边界集、回归场景集。每次模型升级或技能调整之前先把这三个评估集跑一遍。某团队一次升级后其他指标都正常唯独一个预算审批场景漏掉了人工确认评估集刚好覆盖到问题才在上线前暴露。没有评估集的团队基本是在靠运气做迭代风险是随机的今天没爆不代表明天不爆。6.3 产品经理的角色从画原型到描述意图最后一种是角色变化它可能比架构变化更麻烦。以前产品经理的核心产出是原型图、状态流、字段规则Agent时代这些仍然有用但最核心的产出正在变成“意图描述”和“边界规则”。你要把用户想要什么结果定义得足够清晰把哪些场景可以自动决策、哪些必须打断用户定义清楚。我们试着让产品经理在需求文档里写两段内容一段用自然语言描述用户的目标和限制条件一段用表格列出Agent不允许做的动作。两次迭代之后研发和模型对接的效率明显提高。这不是让产品经理去学写代码而是让他们开始用可验证的方式描述不确定性。画原型图是“告诉系统怎么做”写意图说明书是“告诉系统为什么做”后者才是Agent产品真正缺少的东西。最后分享一点个人体会。我见过不少项目把Agent架构演进当成“套一层壳”以为页面上嵌一个对话框再把几个接口暴露出来就算搞定。真正做下来你会发现大脑层负责把不确定性变成可执行计划技能层把老系统的价值翻译成模型能理解的动作护栏层给所有随机性兜底。三者里最难的不是大脑而是护栏。我的建议是先搭护栏再做技能最后再优化大脑。演示效果会平淡很多但能上线的系统本来就该先问边界再谈能力。如果只选一个最低成本的起步动作那就是把现有系统的操作按技能清单梳理一遍每条写清楚意图、参数、副作用和审批级别。这一步做完后面接什么架构都会顺手很多。