企业官网建设流程全解析

这是“AI智能体”系列指南的第三篇。前两篇我们把AI智能体的概念拆开了，讲清楚了它不只是一个聊天框，而是一个能感知、会规划、能调用工具、有记忆的循环系统，并且用 Python 搭了一个最小可跑的原型：能读输入、能决定调哪个工具、能把结果整理成回答。但说实话，那个原型距离一个能交给别人天天用的东西还差得很远。这篇要集中解决的就是这个差距：无代码工具到底怎么选、Python 怎么跟无代码配合着用、记忆和知识库怎么做才不出事故、多智能体什么情况下值得上，以及上线之前必须盯住的评估和成本。如果你正准备把一个 AI 智能体放到真实业务里，这篇应该能帮你把最后这段路走顺。

1. 从“能跑的原型”到“能用的产品”

1.1 前两篇留下的真实问题

前两篇的原型做完之后，你大概率会碰到这些事：同一个问题问两次，回答不一样；让它查订单状态，它一本正经地编了一个单号；多聊几轮之后，它忘了用户一开始的需求；还有，用户信息明明在系统里，它却当成新客户来接待。这些问题不是模型不够聪明，而是原型阶段根本没处理“工程约束”。一个能 demo 的 AI 智能体和能上生产的 AI 智能体，差的不是模型能力，而是周边系统：记忆存储、权限控制、日志、超时重试、成本上限、人工兜底。前两篇相当于把发动机造出来了，这篇聊的是怎么把它装进车架、接上方向盘和刹车。

1.2 无代码平台在 2025 年已经不是“玩具”

2025 年这个时间点很关键。无代码智能体平台早就不是早期那种拖几个块、拼一个“伪AI问答框”的程度了。主流平台普遍具备四样东西：可视化的工作流编排、能接入多种大模型、内置知识库和向量检索、以及丰富的插件与 API 连接器。更实际的是，这些平台开始支持版本管理、日志追踪、人工审批节点、甚至导出代码。也就是说，它能从“给你玩一下”变成“能跑正经业务”。我接触过一些团队，第一反应是“无代码是给不懂技术的人用的”，后来发现恰恰相反，研发团队拿它做内部流程自动化效率极高，因为不用写一遍前端、写一遍后端、再写一遍联调。无代码不是妥协，是一种工程选择。

1.3 这篇会反复出现的三个关键词

整篇内容可以浓缩成三件事：多智能体协作、可观测性、成本治理。多智能体不是说非得上多个“人设”才高级，而是当一个任务的判断链太长、工具太多时，拆成多个小智能体反而更可控。可观测性指的是你要能回答“它为什么给出这个结果”“哪一步调用失败了”“上周改动之后效果变了还是变了多少”，没有观测，AI 智能体就是黑盒事故。成本治理更现实，模型调用是要花钱的，尤其当智能体自动跑起来之后，数量和 token 消耗会远超写 demo 时的想象。把这三个词记在心里，后面所有章节都在围绕它们展开。

2. 无代码智能体平台的选型逻辑

2.1 从五个维度给平台打分

选无代码平台，先别比谁的界面好看，比五个硬维度。第一个是部署方式，SaaS 和私有化差别很大，如果业务数据涉及客户订单、个人信息，尽量选支持私有化部署或者至少能承诺数据隔离的。第二个是编排灵活性，重点看有没有分支、循环、并行、人工审批这些节点，很多平台看起来啥都能连，一用到复杂分支就卡住。第三个是模型可替换性，好的平台不会把你锁死在某个模型上，而是允许你按不同节点配置不同模型，甚至接你自己部署的模型接口。第四个是开放能力，说白了就是有没有 API、Webhook、自定义代码节点，这决定了后面 Python 能不能跟它混合。第五个是可观测性，日志保留多久、能不能看到单次请求的完整轨迹、费用统计细不细。我建议你把这五条做成表格，候选平台各打一轮分，比听别人吹半天都管用。

2.2 三类平台各有各的命

市面上的无代码智能体平台，大致能分成三类。第一类是对话机器人型，典型场景是客服问答、营销获客，优点是上线快，缺点是流程编排弱，适合业务部门自己玩。第二类是自动化工作流型，擅长处理工单、审批、通知这类有明确流程的事情，节点丰富，连接器多，适合把智能体嵌进企业业务流程。第三类是低代码应用型，前端可定制、能写部分代码、能接入内部数据库，适合要深度集成到自有系统的团队。没有哪个绝对好，只有匹配不匹配。我见过有人拿第二类平台硬做第三类的事，结果各种受限制，换个平台一周就做完了。选型之前先明确一个问题：你要的是“会聊天的机器人”，还是“能干活的工作流”，这俩的选型方向完全不同。

2.3 一次 PoC 比看一百篇评测有用

我不太信“我用某平台搭了一个超强智能体”这类文章，因为你不知道它的业务复杂度、数据质量、评测标准是什么。最靠谱的方式是自己做一次小范围概念验证：挑 20 个真实业务问题，包含简单的、模糊的、多轮纠缠的，再用同样的提示词在同一类平台上各跑一遍。记录三件事：答对的比率、失败时能不能找到原因、调整一次逻辑需要花多长时间。第三条最容易忽略，但 AI 智能体上线以后一定会反复调，改动成本决定了你的迭代速度。一个平台 demo 惊艳但改起来要等两天，另一个平台中规中矩但改动当天生效，我绝对选后者。另外提醒一句，PoC 用的数据一定要脱敏，别把真实客户信息直接传上去。

3. 用无代码平台搭一个可落地的智能体：完整实操案例

3.1 选一个典型的业务场景

拿一个最常见的场景练手：电商工单自动分类与回复草稿生成。需求长这样：工单进来之后，智能体要读标题和描述，判断它是售前、售后、物流还是发票问题；然后根据知识库里的政策，生成一段回复草稿；如果判断是高危单，比如退款投诉，必须转人工处理，不能自动回复。这类场景非常适合无代码平台做，因为它有清晰的触发条件、决策分支和人工兜底，而且效果能直接测量。同时它够典型，你做完之后换到其他行业，改改知识库和字段名就又是一套。

3.2 搭建主流程的六个步骤

第一步，先建知识库。把常见问题整理成问答对的 Markdown 文件，传进去，平台会做好切片和向量化。第二步，设置触发条件。工单系统通过 Webhook 把数据推给平台，或者平台定时拉取待处理工单。第三步，画主流程：分类节点、知识库检索节点、生成回复节点、风险判断节点、通知节点。第四步，配置模型参数。低风险单可以用便宜的小模型，高风险单用更强的模型，别整个流程一刀切。第五步，加一个置信度判断。分类和风险判断都输出一个 0 到 1 的分数，只有足够确定才自动回复。第六步，接人工节点。风险单自动发到企业即时通讯群，让真人接手。六步做完，核心流程就已经能跑了。

3.3 实操里我死磕的两个细节

第一个细节是提示词里必须明确禁止废话。模型直接生成回复时，很容易带出“作为语言模型，我无法...”或者“如果您需要进一步帮助，请随时告诉我”这种套话。我的做法是在生成节点的系统提示词里写：直接输出可发送给客户的回复正文，不要解释，不要寒暄，不要提及你是 AI。第二个细节是知识库不要整篇 PDF 往里丢，按问题场景拆成条目式文档。同一批知识，整篇上传时模型经常抓到无关段落，拆成问答对之后准确率明显上升。还有，检验每个节点的输出格式，能配置 JSON 输出就配置，后面接分支判断会省很多事。

4. Python 与无代码的“混合开发”模式

4.1 为什么要混编，而不是二选一

只靠无代码平台，你会在两个地方撞墙：一是复杂计算和内部系统对接，平台自带的节点没法覆盖；二是不可控的逻辑，平台里画几十个节点又乱又难调。反过来，全写 Python 也不现实，AI 智能体的流程天然带有很多分支、并行、人工审批，代码里硬写这些非常痛苦，而且每次改流程都要改代码、重新部署。所以生产环境最常用的其实是混合架构：无代码平台管流程，Python 管能力。流程看得见，能力够灵活。很多成熟团队的做法是，平台里只留主干节点，凡是需要复杂处理的地方，都指向一个自定义代码节点或者 HTTP 请求节点，背后是 Python 服务。

4.2 把 Python 能力封装成一个接口

最典型的做法是，在 Python 侧写一个服务，暴露一个 HTTP 接口，无代码平台通过 HTTP 节点调用。举个例子，工单分类逻辑里可能要查询会员等级、历史订单、黑名单，这些平台很难直接做到，就在 Python 里实现。伪代码如下：

# 伪代码：把工单分类能力封装成 HTTP 接口 import json def classify_workorder(title: str, content: str) -> dict: # 1. 先查缓存，命中直接返回 # 2. 调用模型分类 # 3. 做置信度校准 # 4. 写结构化日志 return {"category": "售后", "confidence": 0.91, "level": "high"} def handler(request_data): try: title = request_data.get("title", "")[:200] content = request_data.get("content", "")[:2000] if not title and not content: return {"status": 2, "message": "empty inputs"} result = classify_workorder(title, content) return {"status": 0, "data": result} except Exception as e: # 任何异常都要让调用方知道，走降级或人工 return {"status": 1, "message": str(e)}

真正工程化的时候还会有鉴权、超时、限流、日志。别小看这个封装，它把模型调用、业务规则、数据访问全部收拢到一处，无代码平台那边只看到一个统一接口，出问题也容易排查。

4.3 连接层要做好的四件事

Python 和无代码平台连起来，连接层是最容易出事的地方。第一件是鉴权，平台调用你的接口时要带一个内部 token，你在 Python 侧校验，别把接口裸奔在公网上。第二件是超时与重试，大模型调用本身就慢，如果业务要求五秒内响应，要在 Python 侧做好超时控制，失败重试最多两次，再失败就返回明确错误，让流程走人工兜底。第三件是幂等，比如智能体要调用“创建退款单”这类动作，如果请求超时了平台重试，你这边就会执行两次，解决办法是请求里带唯一业务 ID，Python 侧先去重。第四件是日志，每次调用的入参、出参、耗时、错误原因全部记录下来，这不是给开发看的，是给后面做评估和排障用的。

5. 智能体的长期记忆与知识库，正确打开方式

5.1 记忆要分四层，不能一锅炖

很多人理解的“记忆”就是让 AI 记住对话历史，但这个理解在真实业务里不够用。我的工程习惯是把记忆分四层：第一层是会话级记忆，存最近几轮对话，主要用于上下文连贯；第二层是用户画像，存偏好、标签、历史诉求，需要持久化到业务库；第三层是业务事实，比如订单状态、会员等级，这层千万不能靠模型记住，必须通过工具实时查询；第四层是长期摘要，跨会话的要点记录，可以向量化存储。无代码平台默认只给你第一层，后面的都要自己接。实操时，每个对话请求都带上用户 ID，Python 服务根据用户 ID 拉取画像和摘要，再把业务事实通过接口查询后拼进提示词，这样它的“记忆”才是可靠的。

5.2 向量检索只是候选召回，不是最终答案

知识库用的向量检索，本质上是把问题转换成向量，找语义相近的片段。但很多人把它当成了精准搜索，这是认知误区。向量检索的结果只能算“候选”，必须再经过规则过滤和排序才能交给模型。比如召回分数低于某个阈值的片段直接丢弃，带敏感标签的片段对普通用户不可见，有明显时效性的政策要检查有效期。有个真实教训：某团队把最新价目表传进知识库，但旧文档没删，向量检索把新旧两条都召回了，模型自己挑了一条过期的来回答，结果报错价引来投诉。所以知识库维护的核心不是“传进去”，而是“管起来”：版本、有效期、适用人群、下架机制，一个都不能少。

5.3 更新和清理比首次建设重要十倍

知识库上线只是起点，真正的日常工作是更新和清理。我建议每周做一次增量更新，新增内容走同样的切片和索引流程；每月做一次整体重检，删除已废弃的文档，重建向量索引，避免旧数据残留。切片方式也值得讲究，按标题、章节、语义边界切，不要固定按字符硬切；每个切片 400 到 500 字，相邻切片留 20 到 50 字重叠，可以避免切断一句话影响召回。检索的 TopK 我一般设 5 到 8，太少会漏，太多噪声会把模型带偏。最后，必须做用户级权限隔离，不同角色的人只能检索到对应权限范围的知识，这一步能在接口层通过传参实现。

6. 多智能体协作的设计模式

6.1 三种真正用得上的协作模式

多智能体不是越多越好，但有些场景确实需要拆。第一种是编排者-执行者模式，一个“调度者”负责拆解任务，其他“执行者”各干各的，比如一个查库存、一个算价格、一个写回复，调度者汇总结果。第二种是路由模式，开头一个意图分类节点，把请求分流到不同的专业智能体，比如投诉、售前咨询、技术故障各自走各自的流程。第三种是流水线模式，上游智能体的输出作为下游的输入，比如先做信息提取，再做合规检查，最后生成回复。选哪种，取决于任务之间是并行、分流还是顺序依赖。这几种模式在无代码平台里都能实现，本质上是不同的流程拓扑。

6.2 什么时候不应该上多智能体

我最想劝你的是：能用一个智能体干完的事，绝对不要拆成两个。多智能体会带来三个直接问题：上下文在传递过程中信息衰减，A 告诉 B 的时候已经丢了细节，B 再传给 C 又丢一层；调用次数变多，成本和延迟都涨；出错时排查链路变长，你要一层一层定位是哪个环节出了问题。所以判断标准很简单：如果任务拆解规则明确，而且每个环节之间只需要传递结构化数据，才值得拆。如果拆完还得靠自然语言来回传达，那基本等于把错误放大给下一级。宁可让一个智能体多做几步，配合工具调用，也别为了架构好看硬上多体。

6.3 多智能体设计的三条硬约束

如果确实要上协作，有三条硬约束必须写进流程。第一条，给每个智能体限定上下文范围，别把全量历史都传给下一个，只需要传结构化后的结果摘要。第二条，全局请求 ID 必须贯穿所有子调用，无论是日志还是追踪，任何一个结果都要能问到源头上。第三条，任何子智能体失败都要有兜底路径，比如重试一次，再失败就降级到静态规则或者转人工，绝对不能让它“沉默地失败”，否则用户那边等到的就是超时或乱答。再加一条经验：子调用之间的数据格式尽量用 JSON，别让智能体自己用自然语言描述结果，自然语言既不稳定，也不好做后续判断。

7. 上线前必须考虑的评估、成本与治理

7.1 先建一小组离线评估集，再谈上线

没有评估集就上线，等于是盲飞。我的做法是，从历史真实数据里整理出 80 到 100 条典型输入，每一条都人工标注期望行为：该分到哪个类、回复里必须包含哪几个关键信息、该不该转人工。每次修改提示词、换模型、调参数，都拿这套数据跑一遍回归。评估指标不用复杂，核心看四个：任务完成率、人工介入率、工具调用成功率、端到端延迟。这四个指标能覆盖大多数业务场景。有个容易出现的问题：只准备“干净数据”，全部是标准表述，真实用户说话乱七八糟一样答不上来。所以要专门留 20% 的脏数据，比如错别字、中英混输、口语碎片，放进评估集里一起看。

7.2 成本怎么估算，怎么控制

模型调用成本是智能体项目中容易被低估的板块。给一个直观的估算方法：假设每天要处理 1000 个请求，每个请求约消耗 5000 个输入 token 和 2000 个输出 token，再按某商用模型的参考价格（输入约 0.06 元/千 token、输出约 0.3 元/千 token）算，单次请求成本约 0.9 元，一天就是 900 元，一个月按 22 个工作日算接近两万元。这还是只是单模型，如果中间调用多次或者知识库检索把上下文撑大，成本会更高。控制办法有三个：一是低价值请求用便宜的小模型，把大模型省给复杂任务；二是在检索节点限制召回长度，只把最相关的片段拼进提示词；三是给相似问题加结果缓存，短时间内命中缓存就不用再调模型。

7.3 安全治理的清单，照着检查

上线前最后过一遍安全清单，每一条都不能省：权限最小化，智能体只能访问完成任务所必需的数据，绝不能给它生产库的写权限；日志完整，记录每一次模型输入和输出，方便出事故后追溯；敏感字段脱敏，身份证号、手机号、地址这类信息在进入模型前必须遮蔽；人工兜底，高危操作必须有人审批；一键下线，万一线上出问题，能立刻暂停自动流程切回人工，而不是等到发版。把这条清单当成强制要求，而不是“有空再弄”。做过几个项目之后你会发现，智能体本身出错不可怕，可怕的是出错之后没有日志可查、没有开关可关、没有人工可接。

8. 常见问题与排查思路实录

8.1 高频问题速查表

这张表不是万能药，但大部分新团队的“诡异问题”最后都能落回这几类。排查的顺序也有讲究：先看日志确认是哪一步出错，再测模型输出，最后才怀疑平台，不要在第一步就推翻整个流程。

8.2 两类最容易藏起来的隐蔽问题

第一类是从测试到生产的数据分布变化。测试数据是手工整理的，看起来很正常，真实数据一进来全是口语和噪音，效果立刻崩。解决办法是上线初期先“灰度过”，只放一部分流量进来，拿真实输入回填评估集，把模型看不明白的样本收集起来做针对性优化。第二类是平台升级或者模型版本漂移。无代码平台后台可能悄悄升级了默认配置，模型服务商也可能调整了版本，表现在外就是“什么都没改，效果却变了”。预防办法是把模型版本固定下来，每次平台升级先看发布说明，再跑一遍离线评估集，确认没有回归再切换到生产。

8.3 最后分享一点个人体会

做了几个 AI 智能体项目之后，我的体会特别朴素：一个智能体好不好用，不取决于它偶尔多聪明，而取决于它犯错时你多久能发现、多久能修正、多久能兜住。无代码和 Python 从来不是对立关系，一个负责让流程透明，一个负责让能力可控。把数据流、日志、权限、降级、成本这些“不性感”的东西做扎实，AI 智能体才能真正从玩具变成工具。希望你搭完第一个能上生产的智能体时，也有这种感觉。