1. 从“功能堆叠”到“意图驱动”：通用Agent到底在改什么过去十几年，我们做软件的方式基本没变过：产品经理画页面，后端定义接口，前端拼组件，测试写用例，最后打包发版。用户打开一个App，看到的是一个个功能入口——点“新建订单”、点“导出报表”、点“发送通知”。这套范式我称之为“功能堆叠式架构”，它的核心假设是：用户知道自己要什么，并且愿意学习你设计的操作路径。但通用Agent的出现，把这个假设直接掀翻了。用户不再想学你的菜单在哪、按钮叫什么，他只想说一句“帮我把上个月华东区退货率超过5%的订单整理出来，发给供应链负责人”。这句话背后可能涉及数据库查询、权限校验、报表生成、消息推送、甚至跨系统调用，但在Agent视角里，它就是一个意图，而不是五个功能。这就是标题里说的“大脑+技能+护栏”的由来。大脑负责理解意图、拆解任务、规划步骤；技能是具体执行单元，可以是API、脚本、工具函数，甚至另一个Agent；护栏则是安全边界、权限控制、输出校验和人工确认机制。传统软件架构里的“页面+接口+数据库”三层，正在被这三样东西重新组织。我自己的判断是，这不是简单的“加个AI助手”，而是软件形态的底层迁移。就像当年从桌面软件到Web应用，不是把窗口搬到浏览器里，而是重新定义了交付方式。通用Agent带来的变化，是软件从“人找功能”变成“功能找人”，从“操作界面”变成“意图接口”。1.1 传统架构为什么撑不住Agent场景传统软件架构的核心是确定性。你点一个按钮，后端执行一段逻辑，返回一个结果。整个链路是预设好的，输入输出边界清晰。但Agent场景天然是非确定性的：用户说“帮我处理一下客户投诉”，这句话可能对应十几种操作路径，取决于投诉内容、客户等级、历史记录、当前库存、甚至天气（比如物流延迟）。我试过在一个内部工具里硬塞Agent能力，结果发现最大的瓶颈不是模型能力，而是接口粒度太粗。传统API都是按业务功能切的，比如createOrder、cancelOrder、queryOrder，但Agent需要的是更细粒度的原子操作：查客户ID、查订单状态、查库存、查物流、发通知、写日志。你让Agent去调createOrder，它得先知道这个接口需要哪些参数、参数格式是什么、有没有前置条件，这些信息在传统文档里往往是缺失的。另一个问题是状态管理。传统软件里，状态是显式的：用户登录了、购物车有东西、订单已支付。但Agent执行任务时，状态是隐式的、动态的、跨会话的。它可能今天查了一半，明天继续查，中间还穿插了其他任务。传统架构里没有为这种“长期运行、多步规划、动态中断”的场景设计过。所以我说“终结”不是危言耸听，而是传统架构的抽象层次和Agent的需求层次不匹配。你需要把软件拆成更小的、可组合的、带语义描述的“技能单元”，而不是按页面和接口来组织。1.2 “大脑+技能+护栏”到底怎么理解我用一个实际场景来解释。假设你要做一个“智能报销Agent”，用户说“帮我把上周出差的发票报了”。大脑要做的事：识别意图是“报销”，提取时间范围“上周”，找到“出差”相关的发票，判断报销类型（交通、住宿、餐饮），检查公司报销政策，生成报销单，提交审批，通知用户。技能包括：发票OCR识别、差旅标准查询、报销单生成、审批流触发、消息推送。每个技能都是一个独立函数或服务，有明确的输入输出和语义描述。护栏包括：金额超过5000需要人工确认、发票重复检测、敏感信息脱敏、审批权限校验、操作日志留痕。这三层里，大脑是最不稳定的，因为它依赖模型能力；技能是最需要工程化的，因为要保证可靠性和可观测性；护栏是最容易被忽视但最不能省的，因为一旦Agent做错事，后果比传统软件严重得多。我个人的经验是，技能层要尽量薄，护栏层要尽量厚。技能薄意味着每个技能只做一件事，容易测试和替换；护栏厚意味着每个关键操作都有校验和确认，不会因为模型幻觉导致灾难性后果。2. 技能层设计：把软件拆成Agent能听懂的“积木”传统软件拆模块是按业务域拆的，比如用户模块、订单模块、支付模块。但Agent需要的拆法不一样，它需要的是语义原子性——每个技能对应一个明确的动作，输入输出都是结构化数据，并且有自然语言描述。我踩过的一个坑是：把queryOrder这种复合接口直接暴露给Agent，结果Agent经常传错参数，因为它不知道orderStatus的枚举值有哪些，也不知道startTime和endTime的格式要求。后来我把queryOrder拆成了searchOrdersByStatus、searchOrdersByTimeRange、getOrderDetail三个技能，每个技能只接受最简参数，并且在描述里写清楚枚举值和格式示例，Agent的调用成功率直接从60%提到了90%以上。2.1 技能描述的写法比技能本身更重要很多人以为技能层就是写几个函数，其实技能描述才是核心。Agent靠描述来理解这个技能能干什么、什么时候用、参数怎么传。描述写不好，技能再多也没用。我总结了一个技能描述的模板，实测下来Agent理解准确率最高：name: search_orders_by_status description: 根据订单状态查询订单列表，返回订单ID、客户名称、金额、创建时间。适用于需要按状态筛选订单的场景。 parameters: status: type: string enum: [pending, paid, shipped, completed, cancelled] description: 订单状态，必须是枚举值之一 limit: type: integer default: 20 description: 返回结果数量上限，最大100 returns: type: array items: order_id: string customer_name: string amount: number created_at: string关键点：枚举值必须写全，默认值必须写，返回结构必须写。这三样缺一个，Agent就容易瞎猜。我见过太多团队只写一句“查询订单”，然后抱怨Agent不好用。2.2 技能粒度怎么把握：一个实操判断标准技能拆得太细，Agent规划步骤太多，容易出错；拆得太粗，Agent理解不了，也容易出错。我的判断标准是：一个技能对应一个不可再分的业务动作，且这个动作有明确的成功/失败状态。比如“发送通知”是一个技能，“生成报表”是一个技能，但“生成报表并发送”就不是一个技能，因为它是两个动作。反过来，“查询订单”如果包含“按状态查”和“按时间查”两种逻辑，那就应该拆成两个技能，因为它们的参数和语义不同。还有一个经验：技能数量控制在20-50个之间。太少覆盖不了场景，太多Agent选择困难。如果超过50个，考虑加一层“技能分组”或者用路由Agent先做粗分类。2.3 技能的可观测性：别让Agent变成黑盒传统软件里，一个接口调用失败，你看日志就知道哪一步错了。但Agent调用技能时，你可能只看到“任务失败”，不知道是大脑规划错了，还是技能执行错了，还是护栏拦截了。我的做法是给每个技能加结构化日志，记录：调用时间、调用参数、执行耗时、返回结果、错误码。然后在大脑层加决策日志，记录：意图识别结果、任务拆解步骤、技能选择理由、护栏触发情况。这两层日志合起来，才能定位问题。注意：技能日志里不要记录敏感数据，比如身份证号、银行卡号。护栏层要做脱敏，日志层也要做脱敏，这是两回事。3. 护栏层：Agent越能干，护栏越要狠护栏这个词听起来像限制，其实它是信任的基础。没有护栏，你不敢让Agent碰生产环境；有了护栏，你才敢让它自动执行。我见过一个团队，Agent能力很强，但因为没有护栏，一次误操作删了测试库，结果整个项目被叫停。护栏不是拖慢速度，而是让你敢踩油门。3.1 护栏的四个层次我把护栏分成四层，从外到内：第一层：输入护栏。用户输入进来先过一遍，检测敏感词、注入攻击、越权意图。比如用户说“帮我删除所有订单”，输入护栏应该直接拦截，或者转人工确认。第二层：规划护栏。大脑拆解任务后，检查步骤是否合理。比如Agent计划先“删除订单”再“查询订单”，这明显逻辑有问题，规划护栏应该拦截。第三层：执行护栏。技能执行前，检查权限、参数范围、频率限制。比如Agent要调用“转账”技能，执行护栏应该检查金额是否超限、收款方是否在白名单。第四层：输出护栏。技能返回结果后，检查是否包含敏感信息、是否符合格式要求、是否需要人工复核。比如Agent生成了报销单，输出护栏应该检查金额是否超过差旅标准。这四层里，执行护栏最重要，因为它是最后一道防线。我的经验是：所有写操作必须过执行护栏，所有批量操作必须加人工确认，所有涉及资金的必须加二次校验。3.2 人工确认怎么设计才不烦人护栏太严，用户觉得烦；护栏太松，又不敢用。我的做法是分级确认：操作类型确认方式示例只读查询无需确认查订单、查库存单条写操作轻确认（弹窗）修改单个订单状态批量写操作强确认（输入确认词）批量取消订单资金操作二次校验（验证码）发起退款删除操作人工审批删除客户数据轻确认就是弹个窗，用户点“确认”就行。强确认要求用户输入“确认执行”四个字。二次校验走短信或邮件验证码。人工审批走工单系统。这套分级下来，用户日常查询完全无感，只有高风险操作才需要确认，体验和安全的平衡点比较好找。3.3 护栏的“熔断机制”：什么时候该让Agent停下来Agent最怕的不是做错，而是错了还继续做。所以护栏里必须加熔断机制：连续失败N次、单次执行超过M秒、调用频率超过K次/分钟，直接暂停Agent，转人工。我一般设的阈值是：连续失败3次熔断，单步执行超过30秒告警，超过60秒熔断，调用频率超过100次/分钟限流。这些值可以根据业务调整，但必须有。还有一个容易被忽视的：护栏本身也要有日志和告警。如果护栏频繁触发，说明要么Agent能力不够，要么护栏太严，都需要调整。我每周会看一次护栏触发报告，分析哪些是误拦，哪些是真拦，然后优化规则。4. 从传统架构迁移到Agent架构：一个可复现的实操路径如果你现在手里有一个传统软件，想改成Agent架构，我建议不要推倒重来，而是逐步迁移。我自己的路径是：先加大脑，再拆技能，最后补护栏。4.1 第一步：给现有系统加一个“意图入口”不要动现有代码，先加一个Agent层，它接收自然语言输入，调用现有API完成任务。这个阶段的目标是验证意图识别和任务规划，不追求覆盖所有场景。具体做法：选3-5个高频场景，比如“查订单”“改地址”“开发票”，写对应的技能描述，让Agent调用现有API。这个阶段你会发现很多API的粒度太粗，参数太复杂，这就是下一步拆技能的依据。我试过在一个内部CRM上做这个，第一周只支持“查客户”和“查订单”两个场景，但已经能覆盖60%的日常查询。用户反馈很好，因为他们不用再记菜单在哪了。4.2 第二步：把粗粒度API拆成细粒度技能根据第一步的反馈，把Agent经常调用失败的API拆开。拆的时候注意：每个技能只做一件事，参数尽量少，枚举值写全，返回结构固定。拆完之后，给每个技能写单元测试，确保单独调用没问题。然后让Agent重新跑一遍场景，看成功率有没有提升。我一般要求技能层单测覆盖率90%以上，因为Agent调用技能时没有人工干预，技能本身必须可靠。4.3 第三步：加护栏，从只读场景开始护栏不要一上来就全加，先从只读场景开始，验证护栏规则是否合理。比如先加输入护栏和输出护栏，确保Agent不会返回敏感信息。然后逐步加执行护栏，从写操作开始，先加人工确认，再逐步放开。这个阶段最重要的是收集数据：哪些护栏触发了、为什么触发、是误拦还是真拦。根据数据调整规则，直到误拦率低于5%。4.4 第四步：灰度发布和持续迭代Agent架构不是一次性的，是持续迭代的。我建议用灰度发布：先给10%的用户用，观察一周，没问题再扩到50%，再扩到全量。每次迭代都要看三个指标：任务成功率、护栏触发率、用户满意度。任务成功率低于80%，说明技能层或大脑层有问题；护栏触发率高于20%，说明护栏太严或Agent能力不够；用户满意度低于4分（5分制），说明体验有问题。这三个指标要一起看，不能只看一个。5. 常见问题与排查技巧实录5.1 Agent调用技能失败，怎么定位问题先看技能日志，确认技能本身有没有执行。如果技能没执行，看大脑决策日志，确认Agent有没有选择这个技能。如果Agent选了但没调，看技能描述是不是写得不清楚。如果Agent没选，看意图识别是不是错了。我整理了一个排查顺序：检查技能日志：技能是否被调用？参数是否正确？检查决策日志：Agent是否选择了该技能？选择理由是什么？检查技能描述：描述是否清晰？枚举值是否写全？检查护栏日志：是否被护栏拦截？检查模型输出：Agent的规划步骤是否合理？这个顺序能覆盖90%的问题。剩下10%通常是模型幻觉，需要调整提示词或换模型。5.2 技能数量多了之后，Agent选择困难怎么办这是典型问题。我的做法是加一层路由Agent：先让路由Agent判断任务类型，比如“查询类”“操作类”“报表类”，然后只把对应类型的技能暴露给执行Agent。这样每个执行Agent看到的技能数量控制在10-20个，选择准确率会高很多。另一个做法是技能分组，在技能描述里加category字段，Agent先选类别再选技能。这两种方法我都用过，路由Agent效果更好，但成本更高；技能分组成本低，但准确率略低。5.3 护栏误拦太多，用户抱怨怎么办先分析误拦原因。常见原因有三个：规则太严、阈值太低、上下文缺失。规则太严就放宽，阈值太低就调高，上下文缺失就在护栏里加更多上下文信息。比如“金额超过5000需要确认”这条规则，如果用户经常报销5000左右的差旅费，就会频繁触发。这时候可以改成“金额超过5000且不是差旅费需要确认”，或者“金额超过8000需要确认”。规则要跟着业务走，不能拍脑袋定。5.4 Agent执行到一半中断了，怎么恢复这是Agent架构特有的问题。传统软件里，一个请求要么成功要么失败，没有中间状态。但Agent执行多步任务时，可能执行到第三步中断了，前两步已经生效。我的做法是给每个技能加补偿逻辑：如果后续步骤失败，自动回滚前面的步骤。比如“创建订单”失败了，就回滚“扣库存”。如果回滚也失败，就记录到待处理队列，人工介入。另一个做法是任务快照：每执行一步就保存状态，中断后可以从快照恢复。这个成本高一些，但适合长流程任务。注意：补偿逻辑不是万能的，有些操作不可逆，比如“发送通知”。所以护栏层要在执行前就判断哪些操作不可逆，不可逆操作必须加人工确认。5.5 模型升级后，Agent行为变了怎么办这是很现实的问题。模型升级后，意图识别和任务规划可能都变了，之前调好的提示词可能失效。我的做法是每次模型升级都跑一遍回归测试，用固定的测试集验证任务成功率和护栏触发率。如果指标下降超过5%，就回滚模型或调整提示词。测试集要覆盖：高频场景、边界场景、异常场景。我一般准备50-100个测试用例，每次升级跑一遍，半小时就能出结果。6. 我对“大脑+技能+护栏”架构的几点个人体会第一，大脑不是越强越好，而是越稳越好。我见过太多团队追求模型能力，结果Agent经常“自作聪明”，反而不好用。稳定、可预测、可解释，比聪明更重要。第二，技能层是工程活，不是AI活。技能描述、参数设计、错误处理、日志记录，这些都是传统后端工程师的活。不要指望AI工程师把技能层做好，他们更擅长调模型。第三，护栏层是产品活，不是技术活。哪些操作需要确认、确认方式是什么、阈值怎么定，这些是产品经理该想的事。技术团队可以给建议，但最终决策应该是产品。第四，迁移是渐进的，不是革命性的。不要想着一天之内把传统软件改成Agent架构，先从几个场景开始，跑通了再扩。我自己的经验是，一个中等复杂度的系统，迁移周期在3-6个月比较合理。第五，数据是核心资产。Agent架构里，最有价值的不是模型，不是技能，而是执行数据：哪些任务成功了、哪些失败了、护栏触发了多少次、用户怎么反馈的。这些数据决定了你下一步优化什么。所以从第一天起就要做好数据采集和分析。最后分享一个小技巧：给Agent加一个“解释模式”。用户问“你为什么这么做”，Agent能返回决策日志和技能调用记录。这个功能看起来不起眼，但能极大提升用户信任。我试过在内部工具里加这个，用户投诉率直接降了一半，因为他们能看到Agent不是瞎猜，而是有依据的。这个方向还在快速演进，我自己的认知也在不断更新。但有一点是确定的：软件架构的抽象层次正在从“功能”上升到“意图”，谁能把“大脑+技能+护栏”这三层做好，谁就能在下一波软件形态迁移里占住位置。
1. 从“功能堆叠”到“意图驱动”：通用Agent到底在改什么过去十几年，我们做软件的方式基本没变过：产品经理画页面，后端定义接口，前端拼组件，测试写用例，最后打包发版。用户打开一个App，看到的是一个个功能入口——点“新建订单”、点“导出报表”、点“发送通知”。这套范式我称之为“功能堆叠式架构”，它的核心假设是：用户知道自己要什么，并且愿意学习你设计的操作路径。但通用Agent的出现，把这个假设直接掀翻了。用户不再想学你的菜单在哪、按钮叫什么，他只想说一句“帮我把上个月华东区退货率超过5%的订单整理出来，发给供应链负责人”。这句话背后可能涉及数据库查询、权限校验、报表生成、消息推送、甚至跨系统调用，但在Agent视角里，它就是一个意图，而不是五个功能。这就是标题里说的“大脑+技能+护栏”的由来。大脑负责理解意图、拆解任务、规划步骤；技能是具体执行单元，可以是API、脚本、工具函数，甚至另一个Agent；护栏则是安全边界、权限控制、输出校验和人工确认机制。传统软件架构里的“页面+接口+数据库”三层，正在被这三样东西重新组织。我自己的判断是，这不是简单的“加个AI助手”，而是软件形态的底层迁移。就像当年从桌面软件到Web应用，不是把窗口搬到浏览器里，而是重新定义了交付方式。通用Agent带来的变化，是软件从“人找功能”变成“功能找人”，从“操作界面”变成“意图接口”。1.1 传统架构为什么撑不住Agent场景传统软件架构的核心是确定性。你点一个按钮，后端执行一段逻辑，返回一个结果。整个链路是预设好的，输入输出边界清晰。但Agent场景天然是非确定性的：用户说“帮我处理一下客户投诉”，这句话可能对应十几种操作路径，取决于投诉内容、客户等级、历史记录、当前库存、甚至天气（比如物流延迟）。我试过在一个内部工具里硬塞Agent能力，结果发现最大的瓶颈不是模型能力，而是接口粒度太粗。传统API都是按业务功能切的，比如createOrder、cancelOrder、queryOrder，但Agent需要的是更细粒度的原子操作：查客户ID、查订单状态、查库存、查物流、发通知、写日志。你让Agent去调createOrder，它得先知道这个接口需要哪些参数、参数格式是什么、有没有前置条件，这些信息在传统文档里往往是缺失的。另一个问题是状态管理。传统软件里，状态是显式的：用户登录了、购物车有东西、订单已支付。但Agent执行任务时，状态是隐式的、动态的、跨会话的。它可能今天查了一半，明天继续查，中间还穿插了其他任务。传统架构里没有为这种“长期运行、多步规划、动态中断”的场景设计过。所以我说“终结”不是危言耸听，而是传统架构的抽象层次和Agent的需求层次不匹配。你需要把软件拆成更小的、可组合的、带语义描述的“技能单元”，而不是按页面和接口来组织。1.2 “大脑+技能+护栏”到底怎么理解我用一个实际场景来解释。假设你要做一个“智能报销Agent”，用户说“帮我把上周出差的发票报了”。大脑要做的事：识别意图是“报销”，提取时间范围“上周”，找到“出差”相关的发票，判断报销类型（交通、住宿、餐饮），检查公司报销政策，生成报销单，提交审批，通知用户。技能包括：发票OCR识别、差旅标准查询、报销单生成、审批流触发、消息推送。每个技能都是一个独立函数或服务，有明确的输入输出和语义描述。护栏包括：金额超过5000需要人工确认、发票重复检测、敏感信息脱敏、审批权限校验、操作日志留痕。这三层里，大脑是最不稳定的，因为它依赖模型能力；技能是最需要工程化的，因为要保证可靠性和可观测性；护栏是最容易被忽视但最不能省的，因为一旦Agent做错事，后果比传统软件严重得多。我个人的经验是，技能层要尽量薄，护栏层要尽量厚。技能薄意味着每个技能只做一件事，容易测试和替换；护栏厚意味着每个关键操作都有校验和确认，不会因为模型幻觉导致灾难性后果。2. 技能层设计：把软件拆成Agent能听懂的“积木”传统软件拆模块是按业务域拆的，比如用户模块、订单模块、支付模块。但Agent需要的拆法不一样，它需要的是语义原子性——每个技能对应一个明确的动作，输入输出都是结构化数据，并且有自然语言描述。我踩过的一个坑是：把queryOrder这种复合接口直接暴露给Agent，结果Agent经常传错参数，因为它不知道orderStatus的枚举值有哪些，也不知道startTime和endTime的格式要求。后来我把queryOrder拆成了searchOrdersByStatus、searchOrdersByTimeRange、getOrderDetail三个技能，每个技能只接受最简参数，并且在描述里写清楚枚举值和格式示例，Agent的调用成功率直接从60%提到了90%以上。2.1 技能描述的写法比技能本身更重要很多人以为技能层就是写几个函数，其实技能描述才是核心。Agent靠描述来理解这个技能能干什么、什么时候用、参数怎么传。描述写不好，技能再多也没用。我总结了一个技能描述的模板，实测下来Agent理解准确率最高：name: search_orders_by_status description: 根据订单状态查询订单列表，返回订单ID、客户名称、金额、创建时间。适用于需要按状态筛选订单的场景。 parameters: status: type: string enum: [pending, paid, shipped, completed, cancelled] description: 订单状态，必须是枚举值之一 limit: type: integer default: 20 description: 返回结果数量上限，最大100 returns: type: array items: order_id: string customer_name: string amount: number created_at: string关键点：枚举值必须写全，默认值必须写，返回结构必须写。这三样缺一个，Agent就容易瞎猜。我见过太多团队只写一句“查询订单”，然后抱怨Agent不好用。2.2 技能粒度怎么把握：一个实操判断标准技能拆得太细，Agent规划步骤太多，容易出错；拆得太粗，Agent理解不了，也容易出错。我的判断标准是：一个技能对应一个不可再分的业务动作，且这个动作有明确的成功/失败状态。比如“发送通知”是一个技能，“生成报表”是一个技能，但“生成报表并发送”就不是一个技能，因为它是两个动作。反过来，“查询订单”如果包含“按状态查”和“按时间查”两种逻辑，那就应该拆成两个技能，因为它们的参数和语义不同。还有一个经验：技能数量控制在20-50个之间。太少覆盖不了场景，太多Agent选择困难。如果超过50个，考虑加一层“技能分组”或者用路由Agent先做粗分类。2.3 技能的可观测性：别让Agent变成黑盒传统软件里，一个接口调用失败，你看日志就知道哪一步错了。但Agent调用技能时，你可能只看到“任务失败”，不知道是大脑规划错了，还是技能执行错了，还是护栏拦截了。我的做法是给每个技能加结构化日志，记录：调用时间、调用参数、执行耗时、返回结果、错误码。然后在大脑层加决策日志，记录：意图识别结果、任务拆解步骤、技能选择理由、护栏触发情况。这两层日志合起来，才能定位问题。注意：技能日志里不要记录敏感数据，比如身份证号、银行卡号。护栏层要做脱敏，日志层也要做脱敏，这是两回事。3. 护栏层：Agent越能干，护栏越要狠护栏这个词听起来像限制，其实它是信任的基础。没有护栏，你不敢让Agent碰生产环境；有了护栏，你才敢让它自动执行。我见过一个团队，Agent能力很强，但因为没有护栏，一次误操作删了测试库，结果整个项目被叫停。护栏不是拖慢速度，而是让你敢踩油门。3.1 护栏的四个层次我把护栏分成四层，从外到内：第一层：输入护栏。用户输入进来先过一遍，检测敏感词、注入攻击、越权意图。比如用户说“帮我删除所有订单”，输入护栏应该直接拦截，或者转人工确认。第二层：规划护栏。大脑拆解任务后，检查步骤是否合理。比如Agent计划先“删除订单”再“查询订单”，这明显逻辑有问题，规划护栏应该拦截。第三层：执行护栏。技能执行前，检查权限、参数范围、频率限制。比如Agent要调用“转账”技能，执行护栏应该检查金额是否超限、收款方是否在白名单。第四层：输出护栏。技能返回结果后，检查是否包含敏感信息、是否符合格式要求、是否需要人工复核。比如Agent生成了报销单，输出护栏应该检查金额是否超过差旅标准。这四层里，执行护栏最重要，因为它是最后一道防线。我的经验是：所有写操作必须过执行护栏，所有批量操作必须加人工确认，所有涉及资金的必须加二次校验。3.2 人工确认怎么设计才不烦人护栏太严，用户觉得烦；护栏太松，又不敢用。我的做法是分级确认：操作类型确认方式示例只读查询无需确认查订单、查库存单条写操作轻确认（弹窗）修改单个订单状态批量写操作强确认（输入确认词）批量取消订单资金操作二次校验（验证码）发起退款删除操作人工审批删除客户数据轻确认就是弹个窗，用户点“确认”就行。强确认要求用户输入“确认执行”四个字。二次校验走短信或邮件验证码。人工审批走工单系统。这套分级下来，用户日常查询完全无感，只有高风险操作才需要确认，体验和安全的平衡点比较好找。3.3 护栏的“熔断机制”：什么时候该让Agent停下来Agent最怕的不是做错，而是错了还继续做。所以护栏里必须加熔断机制：连续失败N次、单次执行超过M秒、调用频率超过K次/分钟，直接暂停Agent，转人工。我一般设的阈值是：连续失败3次熔断，单步执行超过30秒告警，超过60秒熔断，调用频率超过100次/分钟限流。这些值可以根据业务调整，但必须有。还有一个容易被忽视的：护栏本身也要有日志和告警。如果护栏频繁触发，说明要么Agent能力不够，要么护栏太严，都需要调整。我每周会看一次护栏触发报告，分析哪些是误拦，哪些是真拦，然后优化规则。4. 从传统架构迁移到Agent架构：一个可复现的实操路径如果你现在手里有一个传统软件，想改成Agent架构，我建议不要推倒重来，而是逐步迁移。我自己的路径是：先加大脑，再拆技能，最后补护栏。4.1 第一步：给现有系统加一个“意图入口”不要动现有代码，先加一个Agent层，它接收自然语言输入，调用现有API完成任务。这个阶段的目标是验证意图识别和任务规划，不追求覆盖所有场景。具体做法：选3-5个高频场景，比如“查订单”“改地址”“开发票”，写对应的技能描述，让Agent调用现有API。这个阶段你会发现很多API的粒度太粗，参数太复杂，这就是下一步拆技能的依据。我试过在一个内部CRM上做这个，第一周只支持“查客户”和“查订单”两个场景，但已经能覆盖60%的日常查询。用户反馈很好，因为他们不用再记菜单在哪了。4.2 第二步：把粗粒度API拆成细粒度技能根据第一步的反馈，把Agent经常调用失败的API拆开。拆的时候注意：每个技能只做一件事，参数尽量少，枚举值写全，返回结构固定。拆完之后，给每个技能写单元测试，确保单独调用没问题。然后让Agent重新跑一遍场景，看成功率有没有提升。我一般要求技能层单测覆盖率90%以上，因为Agent调用技能时没有人工干预，技能本身必须可靠。4.3 第三步：加护栏，从只读场景开始护栏不要一上来就全加，先从只读场景开始，验证护栏规则是否合理。比如先加输入护栏和输出护栏，确保Agent不会返回敏感信息。然后逐步加执行护栏，从写操作开始，先加人工确认，再逐步放开。这个阶段最重要的是收集数据：哪些护栏触发了、为什么触发、是误拦还是真拦。根据数据调整规则，直到误拦率低于5%。4.4 第四步：灰度发布和持续迭代Agent架构不是一次性的，是持续迭代的。我建议用灰度发布：先给10%的用户用，观察一周，没问题再扩到50%，再扩到全量。每次迭代都要看三个指标：任务成功率、护栏触发率、用户满意度。任务成功率低于80%，说明技能层或大脑层有问题；护栏触发率高于20%，说明护栏太严或Agent能力不够；用户满意度低于4分（5分制），说明体验有问题。这三个指标要一起看，不能只看一个。5. 常见问题与排查技巧实录5.1 Agent调用技能失败，怎么定位问题先看技能日志，确认技能本身有没有执行。如果技能没执行，看大脑决策日志，确认Agent有没有选择这个技能。如果Agent选了但没调，看技能描述是不是写得不清楚。如果Agent没选，看意图识别是不是错了。我整理了一个排查顺序：检查技能日志：技能是否被调用？参数是否正确？检查决策日志：Agent是否选择了该技能？选择理由是什么？检查技能描述：描述是否清晰？枚举值是否写全？检查护栏日志：是否被护栏拦截？检查模型输出：Agent的规划步骤是否合理？这个顺序能覆盖90%的问题。剩下10%通常是模型幻觉，需要调整提示词或换模型。5.2 技能数量多了之后，Agent选择困难怎么办这是典型问题。我的做法是加一层路由Agent：先让路由Agent判断任务类型，比如“查询类”“操作类”“报表类”，然后只把对应类型的技能暴露给执行Agent。这样每个执行Agent看到的技能数量控制在10-20个，选择准确率会高很多。另一个做法是技能分组，在技能描述里加category字段，Agent先选类别再选技能。这两种方法我都用过，路由Agent效果更好，但成本更高；技能分组成本低，但准确率略低。5.3 护栏误拦太多，用户抱怨怎么办先分析误拦原因。常见原因有三个：规则太严、阈值太低、上下文缺失。规则太严就放宽，阈值太低就调高，上下文缺失就在护栏里加更多上下文信息。比如“金额超过5000需要确认”这条规则，如果用户经常报销5000左右的差旅费，就会频繁触发。这时候可以改成“金额超过5000且不是差旅费需要确认”，或者“金额超过8000需要确认”。规则要跟着业务走，不能拍脑袋定。5.4 Agent执行到一半中断了，怎么恢复这是Agent架构特有的问题。传统软件里，一个请求要么成功要么失败，没有中间状态。但Agent执行多步任务时，可能执行到第三步中断了，前两步已经生效。我的做法是给每个技能加补偿逻辑：如果后续步骤失败，自动回滚前面的步骤。比如“创建订单”失败了，就回滚“扣库存”。如果回滚也失败，就记录到待处理队列，人工介入。另一个做法是任务快照：每执行一步就保存状态，中断后可以从快照恢复。这个成本高一些，但适合长流程任务。注意：补偿逻辑不是万能的，有些操作不可逆，比如“发送通知”。所以护栏层要在执行前就判断哪些操作不可逆，不可逆操作必须加人工确认。5.5 模型升级后，Agent行为变了怎么办这是很现实的问题。模型升级后，意图识别和任务规划可能都变了，之前调好的提示词可能失效。我的做法是每次模型升级都跑一遍回归测试，用固定的测试集验证任务成功率和护栏触发率。如果指标下降超过5%，就回滚模型或调整提示词。测试集要覆盖：高频场景、边界场景、异常场景。我一般准备50-100个测试用例，每次升级跑一遍，半小时就能出结果。6. 我对“大脑+技能+护栏”架构的几点个人体会第一，大脑不是越强越好，而是越稳越好。我见过太多团队追求模型能力，结果Agent经常“自作聪明”，反而不好用。稳定、可预测、可解释，比聪明更重要。第二，技能层是工程活，不是AI活。技能描述、参数设计、错误处理、日志记录，这些都是传统后端工程师的活。不要指望AI工程师把技能层做好，他们更擅长调模型。第三，护栏层是产品活，不是技术活。哪些操作需要确认、确认方式是什么、阈值怎么定，这些是产品经理该想的事。技术团队可以给建议，但最终决策应该是产品。第四，迁移是渐进的，不是革命性的。不要想着一天之内把传统软件改成Agent架构，先从几个场景开始，跑通了再扩。我自己的经验是，一个中等复杂度的系统，迁移周期在3-6个月比较合理。第五，数据是核心资产。Agent架构里，最有价值的不是模型，不是技能，而是执行数据：哪些任务成功了、哪些失败了、护栏触发了多少次、用户怎么反馈的。这些数据决定了你下一步优化什么。所以从第一天起就要做好数据采集和分析。最后分享一个小技巧：给Agent加一个“解释模式”。用户问“你为什么这么做”，Agent能返回决策日志和技能调用记录。这个功能看起来不起眼，但能极大提升用户信任。我试过在内部工具里加这个，用户投诉率直接降了一半，因为他们能看到Agent不是瞎猜，而是有依据的。这个方向还在快速演进，我自己的认知也在不断更新。但有一点是确定的：软件架构的抽象层次正在从“功能”上升到“意图”，谁能把“大脑+技能+护栏”这三层做好，谁就能在下一波软件形态迁移里占住位置。