上篇我们聊了模型选型、提示词工程、工具调用这些偏向“智能体内部”的问题，这篇进入更折磨人的层面：平台边界与运维治理。说句实话，我遇到的生产级事故，几乎九成不是模型不会答，而是平台的能力边界没摸清、线上的行为没法查、改完版本没人能说清影响面。

如果你的智能体还停留在“demo跑通、演示给领导看”的阶段，可能感觉不到这些问题。但一旦上了生产，面对真实用户流量、企业级权限、业务方追责的时候，你会发现低代码平台和自研代码之间的差距，比想象中大得多。这篇下篇专门讲我在多个项目里踩过的8个坑，覆盖平台选型边界、隐性成本、行为审计、可观测性、版本评测和多智能体协同，希望能帮你少走几趟弯路。

1. 平台边界：先想清楚“哪里交给平台，哪里必须自己来”

1.1 坑1：低代码平台触顶的速度，比你预想的快

这类坑我几乎在每次用扣子（Coze）、Dify这类平台做项目时都会踩一遍。前期确实爽，拖拽几下、配上知识库、写几句提示词，三个小时就能跑通一个能对话的智能体。但等到要上生产，问题就像雨后春笋一样往外冒。

我当时接的一个内部客服智能体项目，POC阶段用低代码平台两天就搭出了完整流程：用户提问、检索知识库、大模型生成回答、兜底转人工。领导看完很满意，直接拍板“就用这个上”。结果进了开发阶段，业务方提出要接公司内部的统一登录鉴权，每个用户请求都要带身份令牌；还要接私有RPC网关拿订单数据；另外要求按用户等级走不同的回复策略。平台侧要么不支持，要么只能通过“曲线救国”的方式硬凑——写自定义插件、用Webhook转发、在提示词里塞动态变量。最后发现，绕过平台限制写的胶水代码，比直接用Python从零写一个智能体还多。

这里得说清楚一个本质区别：平台搭建的智能体和用Python搭建的智能体，差别不在于“能不能跑”，而在于“控制和可修改的边界”。平台帮你封装了模型调用、记忆管理、RAG检索、工作流调度，换来的是效率；失去的是对这些环节的精细控制权。你只能在平台定义的抽象层里表达业务逻辑，平台没给你开的口子，你永远无法真正打开它。

我的建议是：立项第一天就列一张“能力边界清单”。把业务必须实现的能力分成三类——平台原生支持、可以通过插件/API间接实现、完全无法实现。如果“完全无法实现”超过两项，或者“间接实现”超过三项，就别硬用平台了。这里有一个很现实的判断标准：凡是涉及公司内部系统深度集成、请求级鉴权、复杂的分布式事务语义的功能，默认按“平台可能不支持”来处理，先验证再承诺。POC可以快，但架构决策不能只图快。

1.2 坑2：混合架构里，编排权归属不清是事故温床

很多团队会选一条折中路线：平台做工作流编排和对话管理，业务逻辑用自研微服务通过工具调用实现。听起来很合理，平台干它擅长的交互，代码干它擅长的事务。但真正跑起来，你会发现在一次智能体对话里，平台要调用多个自研工具，工具之间的状态传递、失败重试、幂等控制，被硬生生拆成了两半。

我团队就出过一次典型事故。我们把一个“订单查询+退款申请”的工具挂在平台上，业务实现在自研服务里。客服智能体在帮用户查询订单时，平台的HTTP工具调用超时了，平台侧自动重发了同一个请求。因为自研服务的接口没做幂等，同一条退款申请被提交了两次。虽然当时仅仅是测试环境，但这个事故把全组人都吓出了一身冷汗——这要是上了生产，就是真实资损。

这件事之后我们定了一条铁律：任何通过平台调用的自研工具，服务端必须实现幂等。具体做法是，每次工具调用都生成唯一的task_id，平台在请求头里带上它，服务端用这个ID做去重。重的请求直接返回第一次的结果，而不是重新执行业务逻辑。同时，所有带事务语义的业务操作（扣款、退款、状态流转）绝不能散落在平台的编排节点里，必须收敛到自己的服务端，平台只负责“决定调用哪个工具”和“传递参数”。

另外还得解决状态归属问题。智能体多轮对话里经常要“先查A再查B，最后汇总C”，如果你把这些中间状态放在平台变量里，一旦平台发布新版本或者会话上下文被压缩，状态就丢了。我们的做法是：平台只保存对话上下文，中间业务状态全部写入自研服务，需要的时候再通过工具反查。虽然多了一次RPC，但换来的是状态可控、可恢复、可排查。

1.3 坑3：上下文窗口预算失控，平台算法边界不透明

这个坑非常隐蔽，几乎所有低代码平台都不会告诉你：上下文窗口是个预算问题，而且必须由你来做分配。平台默认会帮你管理历史消息，看起来很方便，但在生产环境下，这种“自动管理”恰恰是灾难的来源。

我们跑过一个文档问答型智能体，前期测试时准确率不错，上线两周后准确率开始下滑。排查了很久，发现症结在上下文分配上：用户和智能体聊天记录越积越多，平台为了塞进模型窗口，自动压缩了早期对话，但压缩策略完全不可见、不可调。更糟糕的是，业务方上传了一批新的FAQ进知识库，RAG检索结果越来越长，把历史关键信息挤出了窗口。

这里我习惯用“token预算表”来做控制。假设你的模型上下文是8K，必须把预算拆分清楚：系统提示词1500、任务说明与格式约束2000、RAG检索结果2500、历史对话摘要1000、工具返回结果1000。哪里超了，就必须牺牲哪里，绝不能所有模块放任自流。如果平台不给你设置各部分上限的能力，你就只能放弃平台，或者自己封装一层中间层，通过SSE流式接口解析大模型的流式输出，自己做上下文裁剪和消息注入。

道理很简单：大模型的上下文是有限资源，和你的云服务器内存一样，谁不规划谁就会在线上出事。平台解决的是“帮你把消息糊在一起塞给模型”，解决不了“哪些内容更重要、哪些必须舍弃”的决策问题。这个决策权，生产级项目里你最好牢牢握在自己手里。

2. 成本与锁定：平台的“隐身税”必须提前算清

2.1 坑4：免费额度只是诱饵，行为漂移才是真正的大坑

低代码平台最常见的套路是低门槛入驻：免费额度看起来很大方，但生产级用量一上来，价格就变得特别“真实”。我见过不止一个团队，前期用免费额度做了MVP，上线三个月后账单翻了几十倍，而且还没法轻易迁走——工作流、变量、知识库全在平台上，导出格式还不完全兼容。

更隐蔽的是行为漂移。平台不是稳定的运行环境，它的组件版本、内置模型、限流策略都说变就变。你今天调试好的智能体，可能因为平台一次升级，行为就变了。我遇到过一次，智能体原来调用工具时传的是字符串参数，平台升级后自动做了类型转换，某些情况下把数字参数变成了字符串，下游服务直接报参数校验失败。这类问题你没法在自己的代码里查，因为你的代码根本没变，变的是平台的运行时环境。

针对这个问题，我的做法是三层防御：

第一，每周把平台上的智能体配置、工作流JSON、知识库版本导出一次，提交到公司代码仓库。不要嫌麻烦，这是最廉价、最保底的逃生通道。平台万一出问题，至少你有恢复的依据。

第二，在平台的调用层之上，自己封装一层适配接口。不管底层是扣子、Dify还是未来某个新平台，上层业务只依赖你自己的接口。换平台的时候，改适配层，而不是改业务代码。

第三，上线前把平台的关键行为指标记录下来，比如工具调用的默认超时时间、重试次数、消息压缩触发阈值。平台升级后做一次行为对比测试，用固定的测试集跑一遍，看响应差异。出现不可接受的漂移，就要跟平台方确认版本，必要时主动固定平台版本。

我在多个项目里的深刻体会是：平台给你效率是真实的，平台给你锁死也是真实的。入场之前就要想好退场方案，这不是过度担心，而是生产系统的基本职业素养。

3. 运维治理：追因果链比追代码更难

3.1 坑5：行为审计缺失，事后根本查不清“它为什么这么答”

做生产级智能体，你迟早会遇到一个问题：用户投诉说“智能体给我承诺了全额退款，结果没退”，你打开后台，发现日志里只有一句用户输入和一句智能体输出，中间发生了什么，完全查不到。

传统软件排查bug，看代码、看日志、看调用栈就行。但智能体的行为逻辑是大模型推理出来的，同样的输入，换一个模型版本、改一句提示词、知识库增删一篇文档，结果都可能是另一个样。没有决策链路记录，你根本没法判断问题是出在模型理解、检索质量还是工具执行。

我推荐的行为审计方案，是对每一次会话记录结构化日志，至少包括：用户的原始输入、系统注入的提示词版本、RAG检索返回了哪些文档片段（最好带上文档ID和得分）、智能体决定调用哪个工具、传给工具的参数、工具返回的结果、最终回复给用户的内容，以及每次流式输出的关键中间态。用JSON Lines格式落盘，每行是一次完整的决策事件，既方便写入日志系统，也方便后续按会话ID聚合回溯。

{ "session_id": "c9f3a2...", "timestamp": "2025-07-18T14:23:01Z", "event": "tool_call", "agent_id": "after-sales-agent-v2", "user_id": "u_10032", "prompt_version": "prompts/after-sales/20250710_v3", "model": "claude-sonnet-4.5", "tool_name": "refund_query", "tool_input": {"order_id": "20250701001", "user_id": "u_10032"}, "tool_result": {"status": "success", "refund_amount": 299.00} }

刚开始你可能觉得每一条都记录太啰嗦，但真正出问题的时候，你会庆幸自己留下了这些东西。尤其是涉及资金、承诺、隐私数据处理的智能体，行为审计不仅是技术需求，还是合规底线。

另外，行为审计必须包含身份维度：这次调用是哪个用户发起的，用的是哪个渠道，智能体系统里配置的身份是什么。多智能体场景下还要记录是哪个智能体调用了哪个智能体。行业里讨论的ASI应用风险，很大一部分都指向“智能体的行为不可预测、不可追溯”，而审计日志正是对抗这种不确定性的第一道防线。

3.2 坑6：重上线轻观测，缺可观测性三件套

很多团队把智能体调通之后，直接把日志打了几个console.log就上线了。等到线上出问题，才发现连“智能体现在每秒处理多少请求”“工具调用成功率是多少”“平均一次回答消耗多少token”都答不上来。

生产级智能体要有三件套：Metrics、Logs、Traces。它们的分工很清楚——Metrics看整体健康度，Logs看具体细节，Traces看单次请求的全链路。

传统APM工具看的是接口调用时延和错误率，但对智能体来说远远不够。你需要额外关注这些指标：

实现层面，我推荐基于OpenTelemetry做统一埋点。每次会话开启时生成一个trace_id，贯穿用户请求、平台/自研层的模型调用、RAG检索、工具调用。Span里除了常规属性，还要塞上模型名称、提示词版本、输入输出token量、工具名称和参数。这样任何一个用户说“智能体回答得不对”，你都能从trace里看到完整链路在哪里慢、在哪里出错。

这里要特别提醒：低代码平台自带的“调试面板”只适合开发期用。它通常只能看最近几条会话，没有聚合指标，也不支持按时间范围拉取全量数据，更没法和你公司内部的监控告警打通。生产环境的数据管道，还是得自己搭——通过平台提供的日志导出或Webhook，把数据汇聚到你自己的日志平台或APM系统里。

我们项目里还踩过一个很具体的坑：早期只记录了模型生成的最终答案，没记录流式输出的首字延迟。结果用户普遍反馈“打字半天不回”，我们的响应时延指标却一直很健康，因为指标统计的是完整回复时间，而用户感知的是首字出现的时间。后来加入了“首Token延迟”指标，才发现问题出在RAG检索环节——知识库文档太大，检索耗时将近4秒。这个案例说明，指标的定义必须对应真实的用户体验，而不是只盯着服务端的完成时间。

4. 版本、评测与多智能体协同：最后两道护栏

4.1 坑7：Prompt不改版本、知识库更新不看效果，翻车是必然

如果你觉得Prompt只是写在平台里的一段文字，随便改改就行，那你离生产事故不远了。智能体的行为非常大程度上由“非代码”因子决定：系统提示词、少样本示例、RAG知识库文档、模型版本。这些都是会产生线上影响的“配置”，必须像代码一样做版本管理。

我们内部现在是这么做的：所有Prompt文本都放到Git仓库里，每个线上版本必须有明确的版本号，发布时记录是和哪个知识库版本、哪个模型版本搭配的。平台上的智能体配置，每周同步导出到仓库，形成一个带时间戳的snapshot。

知识库的版本管理同样重要。我们刚做知识库更新时，直接把一批新的售后政策文档导入进去，没有做评测就上线了。结果第二天发现，智能体回答新政策的准确性确实提高了，但一些老FAQ的召回率却下降了13%——因为新增文档占了检索空间，旧的常见问题被挤掉了。如果不是我们刚好维护了一套回归评测集，根本发现不了这个问题，只会听到业务方说“感觉最近没以前好用了”。

所以生产级智能体一定要有一套回归评测集，不需要多庞大，但必须覆盖三条线：正常路径（最常见的用户问题）、边界输入（超长文本、重复提问、多意图混杂）、对抗输入（诱导性提问、越权请求、恶意指令）。我们现在的做法是每个场景至少50条，总共150条左右，每次Prompt或知识库变更后，先离线跑一遍评测集，对比回答质量和关键指标（召回率、拒绝率、工具调用准确率），通过后才允许走灰度。

这里还要强调一点：评测集不能只交给开发自己定。我们吃过亏——开发觉得回答“没问题”的case，业务方一看就皱眉，因为提问方式根本不像真实用户。后来我们把客服部门的历史工单捞出来，挑了高频问题改写成评测用例，评测的可信度才上来。很多人说“智能体难治理”，其实是把评测门槛想高了，真正落地时一套贴近真实场景的回归用例集，能拦住绝大多数低级回归。

4.2 坑8：多智能体协同，别把路由权全部交给模型

如果你在做稍微复杂一点的业务，比如一个客服系统里有主智能体和售后、财务、物流三个子智能体，那多智能体协同的路由问题迟早会找上门。平台自带的多智能体编排通常为了解决一个透传问题：根据用户意图自动选择合适的子智能体。听起来很智能，但这种“自动选择”的可靠性，远没有你想的那么高。

我见过最典型的案例是：用户说“我要退货，顺便问一下什么时候能退款”，主智能体直接把整句话路由到了售后智能体。售后智能体处理了退货，却没有触发财务智能体的退款计算，用户后面又追问了一遍才走了退款流程，体验很差。路由一旦出错，后面的所有环节都会跟着错。

生产级的正确做法是“规则主导、模型补充”。设计路由时，先用可枚举的规则把高频、明确的意图分流掉（用户直接提到“退款”“物流”“投诉”，就走对应分支），只有规则覆盖不了的模糊意图，才交给模型做分类决策。主智能体控制整体流程，子智能体负责单一领域能力，当子智能体失败或超时，必须有兜底降级——通常是明确转接人工。这个降级逻辑必须由你的业务代码决定，而不是让模型自己临场发挥。

多智能体协同另一个容易忽略的点是链路追踪。一次用户请求可能经过主智能体、路由模块、子智能体、工具服务四个环节，必须有一个贯穿始终的trace_id，每个环节的日志都要带上它，不然出了问题，你连这个故事线都拼不出来。我们内部甚至要求子智能体之间的调用也走统一的消息协议，而不是各自自定义格式，否则后期排查多智能体问题就是一场灾难。

还要提一个运维层面的经验：多智能体系统的发布要充分考虑各组件之间的兼容性。子智能体A升级了Prompt，主智能体还按旧的路由规则把问题分发过来，可能就会出现行为不匹配。所以我们发布子智能体时，会先让主智能体按旧逻辑路由，只放5%流量给新版子智能体做影子测试，确认没有兼容性问题才逐步放量。这一步看起来麻烦，但对于多智能体这种相互依赖的系统，灰度发布是唯一安全的路径。

写在最后

这8个坑都是真金白银换来的教训。从平台边界到运维治理，核心其实就一句话：智能体的生产级落地，拼的不是模型多聪明、Prompt写得多花哨，而是你对自己系统的可控程度。平台是加速器，不是护栏；代码是手段，不是目的。早期花点时间做能力边界清单、token预算、幂等设计、审计日志、回归评测集，比上线后熬夜救火划算得多。

我个人实际跑下来的体会是，这套治理框架不需要一步到位。如果你现在还在准备上线的阶段，先解决坑1、坑2、坑6；如果已经在线上了，先补坑5的审计日志；如果经常改Prompt和知识库，坑7评测集尽快做起来。等你把这些事情一件件落地，你会发现智能体线上事故虽然不可能完全消失，但至少每一次事故你都能快速定位、快速止血、避免重犯。