企业官网建设流程全解析

1. 为什么“系统烟囱”是大模型智能体最该啃的硬骨头

做企业架构这些年，真正让我觉得难啃的从来不是某个新技术怎么落地，而是那些立在企业内部多年的“系统烟囱”。所谓系统烟囱，说的是一个企业里各业务部门各自建设、彼此独立、数据不互通的IT系统，典型表现就是：ERP一套账号、CRM一套账号、MES一套账号，报表靠Excel叠加，数据靠人工搬运。最近半年，我围绕基于大模型的自主智能体做了一次深度实践，核心思路不再试图物理拆除烟囱，而是在烟囱之间建立一个能理解业务语义、自主调度跨系统动作的智能体层，让数据按规矩流动，让人少做手工搬运。

这篇笔记适合正在做企业集成、数据平台、AI落地或者数字化转型的人看。如果你正好被十几个系统之间的数据同步问题折磨，或者刚被领导要求“上个大模型项目”，我这几个月的踩坑记录应该对你有用。

1.1 烟囱问题再认识：不是技术债，是组织结构的映射

先讲一个最近带过的项目。客户是一家典型的制造型企业，IT系统不算特别多，但已经够乱：ERP管财务和生产计划，MES管车间执行，OA管审批流程，CRM管客户线索，WMS管仓库，还有五六套历史系统和一堆Excel报表并存，一共11套需要打交道的系统。表面看这是典型的技术架构问题，但只要翻一下组织架构就会发现，每套系统的背后都站着一条业务条线。数据口径、流程归属、权限边界全都不一样。

我接手这类项目的第一反应，通常都是建数据中台或者上集成平台，把烟囱打通。但真动起来才发现，烟囱拆不动不是技术不行，而是没人愿意把自己系统的数据主权交出去。业务部门怕数据口径被改掉，IT部门怕接口被滥用，运维部门怕流程被搞乱。结果“打通”变成“各留一手”，最怕的就是中台最终变成又一个新烟囱，数据没打通，反而多了一层转发。

大模型智能体给我的新启发是：目标不一定是把烟囱拆掉，而是让一个足够聪明的“调度员”在烟囱之间按规矩来回送数据、执行动作。烟囱还是那些烟囱，但数据流动、流程协同的复杂度被智能体兜住了。这个思路在组织里受到的阻力小很多，落地也快得多，因为没有任何一个部门需要交出他的系统主权。

1.2 从集成平台到自主智能体：解决思路的转变

传统集成平台解决跨系统问题的方式，是把每个系统的接口抽象出来，做成ESB或者API网关，然后再用流程编排把动作串起来。这种方式的问题在于，定义流程的人必须事先把所有可能性都想清楚。一个分支判断漏了，整个流程就断了，流程一变，开发、测试、发布整套流程又要重新来一遍。

自主智能体的做法完全不同。它把“要达成什么目标”和“具体怎么调用”分成两层。智能体负责理解目标的意图，比如用户说“帮我查一下上个月华东地区所有在途订单的交付状态，并且把逾期项目的负责人邮件发出来”，它会先拆解出三个子任务：查订单、查交付状态、发邮件，再去调用对应的系统接口。整个过程里，具体走哪条路径是模型基于上下文实时决策的，而不是提前固化死的。

我把这种转变概括成一句话：以前的集成是写剧本，智能体集成是即兴演出，但每个动作都对表。剧本写死了就僵，即兴演出怕跑偏。所以后面所有设计工作，都围绕怎么让即兴演出不跑偏展开。这个前提想清楚，整个项目的技术路线才不会走偏。

2. 自主智能体穿透烟囱的整体设计与技术选型

真正开始做技术方案之前，我先把一个概念问题想透了：自主智能体到底靠什么穿透烟囱？答案是靠三个东西的组合——理解能力、工具调用能力和状态记忆能力。缺一个，这个智能体在复杂企业环境里就跑不起来。

2.1 智能体的三层能力底座：意图拆解、工具调用、记忆状态

我把智能体拆成三个能力层来看，分别对应大脑、手和记事本。

第一层是意图拆解层，负责把自然语言或者事件描述转化成可执行的任务序列。这个环节最考验模型能力，也最容易埋坑。你让模型自己完全自由地去拆解任务，短期看着灵活，长期一定出问题。我见过很多团队做的Demo就是死在这里：模型自由发挥两次，一次步骤是对的，一次步骤是错的，根本没法上生产。原因很简单，没有任何约束的意图拆解，其实是在赌模型的稳定性。

第二层是工具调用层，负责把任务映射到具体系统的具体接口上。这一层不是简单配几个API就完事的，而是要解决参数映射、鉴权、返回结果标准化的问题。比如ERP系统的订单查询接口，传参可能是物料编码加工厂代码，而用户在对话里说的是“华东大区的订单”，中间差着好几层转换。工具调用层如果不做参数转换和语义映射，模型面对这些接口细节会经常猜错。

第三层是记忆状态层，负责在多轮交流、多步骤执行过程中保存上下文和中间结果。跨系统操作最怕的是状态断裂，前面刚查出订单号，后面调发货接口时上下文丢了，订单号变成空值，系统要么报错要么误操作。这个状态层不是简单的缓存，而是要能支撑断点续跑和异常追踪。

这三层不是顺序执行，更像一个循环：理解意图、执行动作、读取结果、判断下一步、再次理解。每一轮都在动态更新状态，这也是它叫“自主智能体”而不是“自动化脚本”的原因。脚本是死的，智能体每一轮都在重新观察现状并决定下一步动作。

2.2 三条实现路线怎么选：流程引擎、低代码集成、大模型编排

在选型阶段，我们系统对比过三条实现路线。第一条是传统流程引擎加模型节点，比如用BPM搭好流程，大模型只负责填单个字段，流程还是人画好的。第二条是低代码集成平台，它把连接器做得很丰富，拖拽就能搭跨系统自动化，再往上叠一层AI助手。第三条是我们最终选的大模型原生编排，让模型做任务分解，代码负责执行与校验。

我们最终选择第三条的原因很简单：客户场景变化太快。流程引擎和低代码平台改一版都要两周，而业务方要求大多数临时查询类需求当天就能响应。但选原生编排不代表放任自由。我们额外加了两道硬约束：第一道是动作范围白名单，模型只能调用语义清单里明确定义的接口动作；第二道是代码层二次校验，所有执行动作都要经过代码逻辑把关，不能只信模型输出。这两道约束是这套方案能上生产的关键。

2.3 语义网关：给每个系统补上“懂人话”的说明书

这里必须说一个我踩了几次坑之后沉淀下来的设计，我给它起名叫“语义网关”。很多技术文章会把智能体跨系统想得很简单：模型调用点HTTP接口不就行了。但实际项目里，每个系统接口的入参、出参、鉴权方式、字段含义都不一样，你让模型直接对接底层API，它很快就会被接口细节淹没。

我们把所有系统接口先过一遍，统一包装成“描述清楚的一个动作”。每个动作包含：接口用途、入参含义、出参结构、调用权限、失败时的可能原因。这部分信息组成一个语义清单，作为模型上下文的一部分。举个例子，某套系统的库存查询接口叫/inventory/query，参数有sitepoint、item_no、include_allocated，语义网关把它包装成“查询可用库存：输入站点编号和物料编号，返回可用数量与在途数量；若返回1001错误码，说明站点编号不存在”。模型看到的是这种结构化描述，而不是光秃秃的接口文档。

语义网关还承担两件看似不起眼但很关键的工作。一是统一鉴权，智能体不再需要维护十几套系统的账号密码，所有调用都由网关转发，网关用服务账号去拿系统令牌。二是统一返回格式，不同系统不管返回XML还是JSON，网关都转换成同一套结构，模型处理起来简单得多。

属于语义动作定义的JSON结构，我们最终长这样：

{ "action_id": "erp.query_order_status", "description": "查询ERP订单当前状态", "params": [ {"name": "plant_code", "meaning": "工厂编号", "required": true}, {"name": "order_no", "meaning": "ERP订单号", "required": true} ], "return": { "status": "订单当前状态编码", "status_desc": "状态编码的中文含义", "qty": "已生产数量", "unit": "计量单位" } }

模型拿到的就是这张清单，上下文干净，字段含义清楚，参数没有歧义。这一个设计直接把我们Demo阶段的接口调用错误率从大概25%压到了5%以下。

3. 实操复盘：让智能体真正跨过系统边界

设计说再多，最终还是要看落地。这一节我把整个实施过程拆成四个步骤详细拆解，每一步都说明白为什么要这么做，以及不做会发生什么问题。整个项目从需求调研到联调上线，前后大概花了两个半月。

3.1 第一步：给每个系统定义数字化身份和接口契约

很多人以为第一步是写Prompt，其实不是。第一步是把你要对接的每一个系统当成一个独立外部实体，先给它写一份数字化身份档案。档案包含四块内容：系统能干什么、不能干什么、怎么调用、找谁确认。

比如ERP系统的档案会写：能力是查询订单、创建采购申请、读取库存余额；边界是不支持直接修改财务凭证；接口契约里列出每个动作的入参出参；紧急情况下找哪个业务负责人确认。CRM系统的档案则完全不同，能力是查询客户线索和联系人信息，但禁止写入价格相关字段，因为价格主数据归ERP管。

这一步看起来繁琐，但价值巨大。一方面，它让模型不会试图去做系统本身不支持的事，比如让CRM系统去修改ERP的价格主数据。另一方面，它让团队成员在排查问题时，不用翻十几个系统的技术文档，一份契约就能定位问题。我们当时花了两周时间，把11个系统整理出37个可开放动作，过程中还发现好几个系统的接口文档早就过期了，连参数名都对不上，顺势推动了一轮接口治理。

有一个值得提醒的细节：整理数字化身份档案过程中，不要只找IT人员聊，一定要拉上业务负责人。因为很多接口字段的真实业务含义，只有业务才说得清，比如“预留库存”在不同部门可能代表完全不同的东西。

3.2 第二步：用意图清单把自然语言转化成可靠动作

模型直接理解自由文本是它的优势，但生产环境不能把宝全押在优势上。我给每个高频场景预先定义了一张意图清单，相当于给模型划定任务边界。意图清单的内容不是流程，而是动作组合的描述。

比如场景“跨系统订单状态查询”，意图清单会包含：从CRM查订单来源，从ERP查订单状态，从MES查生产进度，从WMS查发货情况，然后聚合展示。模型在边界内可以做顺序调整，或者跳过无数据的环节，但不能自己发明新的接口调用。这样设计有两个好处：一是可测试性变好，每个意图可以单独做回归测试，模型升级了也能快速验证；二是出错时的责任边界清楚，动作组合定义得对不对是人的问题，模型没有权限的接口，它即便说错话也调用不了。

我简单画一下当时的执行链路伪代码，方便理解意图清单是如何驱动代码执行的：

def dispatch(user_input, session_state): intent = intent_matcher.match(user_input, session_state) if not intent: return ask_confirm("这句话我理解不了，请换一种说法") tasks = plan_actions(intent, session_state) for task in tasks: result = semantic_gateway.execute(task.action_id, task.params) session_state.append_step(task.action_id, result) if result.status == "failed": return partial_report(session_state) return full_report(session_state)

需要注意的是，意图清单不是写一次就结束的文档。我们每个月会根据实际对话记录更新一批，把用户经常表达但意图清单没覆盖到的说法补进去。模型可以一直接受新说法，但只有确认过的意图才会被纳入执行范围。简单说，模型可以自由说话，但不能自由越权动手。

3.3 第三步：任务分解、多轮对话和状态持久化

跨系统任务通常都是多步骤的，必须有状态管理。我们用了一个简单方案：为每个会话维护一个工作流实例，里面保存当前待办任务、已完成动作、临时数据和最后结果。后续每来一条新指令，智能体先读取工作流实例，再决定继续执行哪一步。

举一个实际任务说明。业务方说“查上海工厂的所有逾期生产工单，并把TOP5供应商的联络方式一起整理成表格”。这个任务要先从MES导出逾期工单，然后按供应商分组计数，再从CRM或主数据系统补供应商联系人。如果MES接口执行比较慢，返回超时了，智能体会把第一步标记为失败，用户可以只让“重试MES那部分”，不用重新跑整个任务。

状态持久化有两个要点：中间结果必须保留完整快照，并且每一步都记录执行痕迹。快照用来支持断点续跑，执行痕迹用来做事后审计。做企业级项目必须明白，智能体越自治，审计越重要，否则出了数据问题根本说不清是哪一步造成的。

这里有一个我反复强调的经验：不要把所有状态都塞给模型自己记。模型上下文窗口再大也有限，而且一旦上下文污染，后面所有决策都会受影响。我把中间结果尽可能收回到代码层管理，只把结构化摘要放回模型上下文。这样模型永远只看到精简过的高质量信息，不会因为灌了一堆原始日志而变傻。

3.4 第四步：兜底、降级和人工闸门

任何AI系统都存在不确定性，所以穿透式智能体必须设计好兜底机制。我们做了三层兜底，可以说没有这三层，这个项目不可能通过客户的安全评审。

第一层是动作级校验。每一个跨系统写操作，都必须在代码层做二次校验。比如创建采购申请时，金额超过阈值、供应商进黑名单、部门预算不足，任何一个条件不满足，智能体就算已经提交成功，也会被代码拦下来，不会真正生效。第二层是流程级降级。如果某个外部系统出现故障或者接口返回持续异常，智能体不会硬闯，而是自动把任务变为“部分完成”状态，把成功和失败的部分分别列出，通知用户由人工决定是否继续。这比反复重试要专业得多，也避免了对上游系统的二次压力。

第三层是人工审批闸门。写操作默认不自动执行，而是生成待确认指令。部门负责人可以在一个类似审批中心的界面，看到智能体打算做的每一步操作，然后批准或驳回。这个设计极大降低了业务方对AI误操作的焦虑。

我见过很多团队觉得加人工闸门会让智能体“不够智能”，宁愿用各种提示词约束模型。但真正在企业跑起来，智能体是否聪明远没有是否可控重要。先把闸门加上，后续再逐步放开部分低频风险操作的自动执行权限，节奏才是对的。这个节奏感，是很多技术团队一开始把握不好的。

4. 落地常见问题与排查实录

把智能体放到真实生产环境，除了架构设计，还有一堆脏活累活要处理。这里挑几个最典型的问题，每个都是我亲身踩过的坑，写出来给后来人做个参考。

4.1 权限模型混乱时怎么过渡

第一个问题往往不是技术，而是权限。11个系统有11套账号体系，有的按角色分，有的按部门分，有的干脆所有人共用一个管理员账号。智能体要用统一身份去执行跨系统操作，不可能先人工登录11次，更不该复用管理员账号。

我们的过渡办法是建立映射表，短期先按“最小权限集会”执行。每个系统只开放智能体真正需要的动作权限，并且使用独立服务账号。业务人员平时怎么审批，智能体就怎么被审批。这样在权限治理完成之前，至少保证了合规底线。治本方案是推动一次SSO改造，但这类改造周期比较长，不应该成为智能体项目卡住的理由。

实际上，把权限映射表做出来以后，很多以前说不清楚“谁能看到什么数据”的部门，反而愿意借这个机会把权限梳理清楚。很多治理项目都是被新系统逼出来的，这是好事。权限映射表做得好，后面所有智能体动作都能追溯到授权记录，审计省了一大半功夫。

4.2 大模型幻觉混入业务数据链路怎么办

跨系统场景里，模型幻觉的危害会被放大。它可能把订单状态从“已生产”说成“已发货”，可能把某个月份的数据凭空补上一个汇总数，还可能看错数字单位。我在项目里总结出三招来防幻觉。

第一招是摘要必须给出处。模型生成的任何业务结论后面，必须带上前置查询的快照ID。用户点一下就能看到原始数据，对不上就属于程序错误而不是模型幻觉。第二招是数值计算不让模型做。涉及金额、数量、占比的运算，全部由代码完成，模型只负责把代码算出的结果组织成自然语言。模型可以总结叙述，但不能碰数字计算本身。

第三招是引导模型在不确定时直接说不确定。做法很简单：在系统提示里明确写“如果查询结果为空或字段含义不明，必须如实反馈缺失项，禁止猜测补充”，同时在意图清单里不允许它自己补接口。实测下来，准确率没降，错误率降了很多，因为至少错误从“自作主张”变成“答不上来”，答不上来还有机会补救。

4.3 老接口不稳定时如何保证整体可用

客户那套ERP和MES系统年限都比较老，接口时常超时，有时还会返回200但内容其实是个错误页。智能体跨系统执行，本质上把这些不稳定因素的暴露面放大了，必须从基础设施层面下功夫。

我们的处理方式，是给每个外部接口做三层包装。第一层是超时和重试控制，超时时间、重试次数、退避策略都按接口历史表现单独配置，不搞一刀切。第二层是返回校验，不只检查HTTP状态码，还会检查返回体结构，明显不是业务数据的返回全部当作失败处理。第三层是熔断与降级，同一个接口短时间内连续失败超过阈值，这个接口会被暂停调度半小时，期间智能体会主动告知用户系统暂时不可用，而不是继续撞墙。

这套机制听着不复杂，但非常有效。上线第一个月，跨系统任务的一次性成功率从不足70%提到了92%以上。剩下的几个百分点，基本都是上游系统真宕机导致的，再往上的解决方式就是做成定时补偿任务，把失败数据写入待处理队列，等系统恢复之后自动补跑。

4.4 速查表：从现象到排查路径

我把最常遇到的几个现象整理成一张表，放在运维群里当速查资料，现在也分享出来。

排查智能体问题有个总原则：先看代码链路，再看模型输出。代码链路是确定的，模型输出是概率性的，拿确定环节去卡不确定环节，才能快速缩小范围。很多团队一遇到问题就怀疑模型，结果查了半天发现是接口参数传错了，方向就反了。

5. 从Demo到生产，我补几句实操体会

项目收尾的时候，客户问了我一句话：这套东西到底是把烟囱拆了，还是让烟囱之间多了一条秘密通道。我的回答是：都算。智能体没有把系统物理打通，也没有统一数据模型，但它在业务语义层面把流程串了起来，让用户不用关心数据到底在哪套系统里。这个层面反而更接近业务人员想要的效果。

我自己总结下来有三条体会。第一条，做这类项目，先低后高。不要一上来就挑战最高难度的大流程自动化，先从查询、汇总、提醒这类只读场景做起，建立信任之后再逐步开放写操作。第二条，把模型当作队伍里能力很强但需要纪律的新人。它很聪明，但你得给它明确的工作范围和汇报机制，没有纪律的聪明在企业里只会闯祸。第三条，一定要做接口治理。智能体项目做得越深入，暴露出来的老系统接口问题就越多，与其说这是AI项目，不如说它顺手帮企业做了一次很好的数据治理体检。

最后再分享一个小技巧：这类项目最好是业务方、IT方、模型开发方三拨人每周一起过一遍实际对话日志，逐条讨论哪些回答有问题、哪些流程卡住了。智能体这类系统最怕的就是闭门造车式迭代，只有把真实业务场景里的对话数据喂回去，系统才会越用越顺手。