企业官网建设流程全解析

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 技能注册表的设计要点

技能注册表是整个架构的核心组件，它的设计质量直接决定了系统的扩展性。我总结几个关键设计点：

这张表里的每一项，都是我在实际项目中踩过坑之后加上的。你可以直接拿去对照检查自己的设计。

5.5 一个最小可用的架构参考

如果你想要一个最小可用的起步架构，我建议包含这几个部分：

• 意图解析层：接收用户输入，输出结构化任务描述
• 规划器：根据任务描述和技能注册表，生成执行计划
• 执行器：按计划调用技能，管理执行状态
• 技能注册表：存储所有技能的元数据
• 护栏层：在输入、执行、输出三个环节做校验
• 轨迹记录器：记录完整执行轨迹，供调试和审计

这个架构不复杂，但五脏俱全。你可以先用它跑通一个简单场景，然后再逐步扩展。记住，架构是长出来的，不是设计出来的。一开始不要追求完美，先让它跑起来，然后在迭代中完善。

6. 这套范式对开发者的实际影响

6.1 后端开发的重心在转移

以前后端开发的核心工作是写业务逻辑：接收请求、处理数据、返回结果。未来后端开发的重心会转向技能封装和护栏设计。业务逻辑本身会被Agent的规划能力替代一部分，但技能的质量和护栏的严谨性会变得更重要。

这意味着后端开发者需要具备一些新技能：理解Agent的规划机制、会写技能描述、能设计合理的护栏规则。这些不是传统后端开发的必备技能，但在新范式下会越来越重要。

6.2 前端会变成"任务界面"而非"功能界面"

传统前端是功能驱动的：这个页面有这些按钮，那个页面有那些表单。未来前端会更多地向"任务界面"演化：用户描述一个目标，界面展示Agent的执行过程和结果。

这对前端开发者来说是个不小的转变。你不再需要为每个功能设计独立的交互流程，而是需要设计一套通用的"任务展示框架"——能展示任务进度、中间结果、异常提示、人工确认请求。这套框架的复用性会很高，但设计难度也不小。

6.3 测试策略需要重构

传统测试是功能测试：给定输入，验证输出。Agent系统的测试要复杂得多，因为同样的输入，Agent可能走不同的执行路径。你需要测试的是任务成功率和异常处理能力，而不是单个功能的正确性。

我现在的做法是：建立任务测试集，每个任务包含多个变体输入，验证Agent能否在各种情况下完成任务。同时，还要做护栏测试，验证异常输入和越权操作能否被正确拦截。这套测试策略和传统测试差别很大，需要重新积累经验。

7. 关于"所有软件只剩大脑+技能+护栏"这个判断

这个判断方向是对的，但"只剩"这个词可能过于绝对。我的看法是：不是所有软件都会变成Agent，但所有软件都会受到Agent架构的影响。

一些简单的工具类软件，可能永远不需要Agent，一个函数就能搞定的事没必要上大脑。但复杂的企业软件、协作软件、决策支持软件，大概率会向这个方向演化。因为用户要的不是功能，是结果。Agent架构能更好地交付结果。

另外，"大脑+技能+护栏"是一个逻辑分层，不是物理部署架构。实际落地时，这三层可能跑在同一个进程里，也可能分散在多个服务中。关键是逻辑上要分清职责，而不是纠结于物理形态。

我在实际项目里的体会是：这套架构最大的价值不是技术上的先进，而是它让软件更贴近人的工作方式。人工作时就是先理解任务、再规划步骤、然后调用各种工具、过程中遵守规则。Agent架构本质上是在模仿这个过程。当软件的工作方式和人的工作方式对齐时，很多以前很难解决的问题——比如跨系统协作、动态流程、异常处理——会变得自然很多。

最后分享一个小技巧：如果你刚开始接触这套架构，不要从技术入手，从观察人的工作流程入手。找一个你熟悉的业务场景，观察一个熟练员工是怎么完成任务的：他先做什么、后做什么、用什么工具、遇到问题怎么处理、有什么规则约束。把这个过程画出来，你会发现，它天然就是"大脑+技能+护栏"的结构。技术实现只是把这个结构翻译成代码而已。