企业官网建设流程全解析

前阵子和一个做客服系统改造的团队交流，聊到一个非常典型的线上事故。他们上线了一个基于大模型的客服 Agent，用来处理售后咨询。结果某个用户问“我的订单优惠没到账，能不能补 20 元话费”，Agent 在上下文里看到一段旧活动的介绍，直接回复“可以补 20 元话费”。但那个活动早就结束了，系统也根本没有发放话费的工具权限。用户拿着 Agent 的回复截图找到平台投诉，运营说这个锅不能算人工客服，产品说用户自己应该再核实一下，算法同学说大模型输出本来就是概率性的，确实管不住。

最后他们还是给用户补偿了这笔钱，然后把 Agent 的这个能力临时下掉了。

这个案例让我一直记着一个问题：当 Agent 开始具备自主性，能自己拆任务、自己选工具、自己给结论时，Agent 出错后的损失，到底该由谁来承担？尤其当用户已经在对话框里点了“确认执行”，是不是就默认用户自担风险？

我的判断是：不能只让用户承担。不是说所有责任都要推给开发方，而是说，在 Agent 具备一定自主性的前提下，单纯用“用户确认过”来闭环责任，既不现实，也不公平。Agent 真正需要的不是一个事后赔付意义上的保险产品，而是一套让风险可定价、可追溯、可约束的责任机制。没有这套机制，损失最终会落在整个链条里信息最少、控制能力最弱的一方身上，通常是普通用户，或者被业务方默默背走。

下面把我目前想清楚的几个层面拆开说，也会给出工程侧的落地动作。

1. Agent 出错，为什么不能只让用户承担

1.1 Agent 的决策链路对用户来说几乎是黑盒

用户看到的是一个对话框，但 Agent 在对话框背后可能做了很多事。一个完整的 Agent 流程大致会经历：用户输入、意图识别、子任务拆分、工具选择、参数填充、动作执行、结果生成。这中间的任何一环出问题，用户都很难感知。

举一个很常见的例子。用户说“帮我统计一下这个表里所有订单金额”，这看起来只是一个普通查询。但一个设计不严格的 Agent 可能会把“这个表”理解成数据库里另一张表，或者把“统计”理解成“下载后跑一段脚本”，甚至触发了一次数据导出。用户看不到工具选择、参数生成和动作执行的过程，他看到的是结果：要么正确，要么不正确。如果结果还不算太离谱，他甚至不知道自己已经被“过度执行”了。

这和传统软件有本质区别。传统软件的行为边界相对固定，用户在一个页面上点按钮，基本能预测会发生什么。Agent 不一样，同一个用户输入，在不同模型版本、不同上下文、不同时间点下，可能走出完全不同的执行路径。用户不可能为一条他自己都无法预知的执行路径负责。

1.2 信息不对称：用户看不见能力边界

从工程视角看，用户和 Agent 之间还存在严重的信息不对称。用户不知道这个 Agent 接入了哪些工具、拥有什么权限、是否具备写操作能力、会不会调用外部 API、上下文有没有被截断。

比如一个客服 Agent，表面上只是聊天，但背后如果接了订单查询、优惠券发放、售后退换货工具，那么用户的一句话就可能触发某个真实动作。用户在输入之前，根本不知道这句话会落在 Agent 的工具边界内还是边界外。这时候让用户承担所有风险，相当于让一个人闭着眼睛签合同。

我并不主张把所有责任都推给用户，同样也不主张把所有责任都推给开发方。用户如果有恶意输入，那就应该承担相应的责任。但在常规使用场景里，用户对一个 Agent 的实际控制能力非常弱，默认免责条款只会让用户对 Agent 的信任变得更低。

1.3 执行链路会把单个错误放大

Agent 出错还有一个特点：错误一旦进入执行链路，影响会被批量放大。

传统的聊天机器人答错一句，通常只是让用户产生不满。但现在的 Agent 不只是生成文本，它可能操作数据库、发送通知、修改配置、调用付费 API。如果它被设计成可以批量处理任务，比如批量处理退单、批量生成合同、批量发送营销短信，那么一个参数错误就可能在短时间内影响上千个用户。

这时候再讨论“用户自己没有核实”，意义已经不大了。用户没有能力在几秒钟内审核一条自动化批量任务的上下文正确性。真正能控制这种放大效应的，是开发方在权限、阈值、审批和回滚上做的设计。

所以回到开头那个问题：“用户点击了确认，责任是不是就在用户？”我的看法是：在 Agent 的决策链路对用户不透明、信息严重不对称、执行错误可能被批量放大时，用户不应该成为默认责任兜底方。合理的责任分配，应该靠近链路上拥有更多控制权、信息和能力的那一方。

2. 责任归属不是一条线，而是一张网

2.1 四个参与方，各自控制不同的环节

在真实项目里，一个 Agent 至少会涉及大模型提供方、Agent 框架或平台、应用开发方、部署运维方、用户这几类角色。每一方控制的东西不一样，出错时的触发点也不一样。

这张表不是为了分锅，而是为了找控制点。合理的责任分配，应该优先由能改变结果的一方承担。用户在多数情况下既看不到中间链路，也改变不了模型输出，让他承担第一责任并不合理。

2.2 最小责任判断单位：能不能回答“为什么”和“凭什么”

我在团队里经常提两个问题，当作责任判断的最小单位。

第一个问题是：为什么 Agent 会做这个动作？也就是能不能从日志和上下文里还原出，它出于什么意图、选了哪个工具、填了什么参数。

第二个问题是：凭什么系统允许它在当前场景下发起这个动作？也就是权限模型、工具注册、阈值设计里，有没有给它这个机会。

如果能回答这两个问题，责任归属才有讨论基础。如果答案只有“模型输出的，我们也没办法”，那整个责任链就没有建立起来。这时候把问题归结为“用户确认过”，只是用一个更站不住脚的责任说法，去掩盖另一个责任缺口。

2.3 免责声明的边界在哪里

很多 Agent 产品会在用户协议里写“AI 生成内容仅供参考，不构成任何承诺”。这个说法在纯文本生成场景有一定合理性。但一旦 Agent 接了工具，能修改数据、能发通知、能触发交易，情况就变了。

用户协议能约束合同双方，但约束不了用户拿不到应有权益时的真实情绪，也约束不了舆论和渠道方。更现实的是，当平台面对大量个人用户时，小额损失通常不是靠法律条款去解决的，而是靠客服策略、赔偿预算和产品机制去补偿。

我不是说免责声明没用，而是说它在 Agent 时代的作用会越来越弱。免责声明解决的是法律形式风险，解决不了产品信任和事实损失。如果一个 Agent 频繁出错，写再多的免责声明，也只是在持续消耗用户的信任。

3. Agent“保险”的本质：先让风险变得可定价、可追溯、可约束

3.1 传统保险模型为什么套不到 Agent 上

传统保险能成立，通常要有一个相对稳定的风险统计基础。比如车险，历史出险数据稳定，保险公司可以通过精算给不同人群定价。

Agent 的风险不一样。模型版本几乎每个月都在变，提示词可能每周都在调，工具接入越来越多，上下文策略也一直在改。过去三个月的错误率，很难用来预测下个月的风险。再加上很多小团队连日志都不一定齐全，保险公司根本没有数据去做定价。

所以“给 Agent 买保险”这件事，在传统精算意义上很难直接落地。更准确的说法是：我们需要让 Agent 的运营风险变得“可保化”。

3.2 可保性的四个前提：可观测、可记录、可控制、可回滚

这四个前提，也正好是一条责任链的基础。一个达不到可保性要求的 Agent，就算买了保险，保险公司也很难正常核赔；一个达到可保性要求的 Agent，哪怕暂时没有保险，也已经在工程上降低了一大批真实风险。

3.3 现实中的类保险机制，能在多大程度上兜底

目前和 Agent 相关的保障机制，大致有几种。

平台赔偿基金比较适合平台型 Agent：用户和 Agent 产生小额争议时先行赔付，用来维持平台信任。它的问题是只能覆盖小额高频，覆盖不了重大损失。

E&O 责任险比较适合做企业服务的 Agent 服务商，但核保要求很高，通常要求团队有清晰的安全设计、日志和版本管理。

SLA 赔偿适合 To B 场景，本质是服务费折扣，覆盖不了用户侧的实际损失。

在我看来，对中小团队最务实的顺序，是先做好日志、权限、审批、回滚，再考虑外部补偿机制。外部补偿只能兜住最后一环，不能替代工程体系。

4. 让 Agent 具备“可保性”的五道工程保障

4.1 权限最小化：不要给 Agent 默认管理员能力

很多项目一开始图省事，把数据库账号完整权限直接放进 Agent 的配置里。这在演示环境没问题，一旦上线就是事故源头。

常规做法是把 Agent 的权限分成三级：

• 只读权限：允许查询订单、查询商品、读取文档。
• 受限写权限：允许创建草稿、标记状态，但不能删除。
• 不可逆操作：删除、转账、发布、批量修改，默认不给 Agent 开放，必须由人工执行。

一个 Agent 只需要查询订单状态，就只给它订单查询工具的只读权限。不要因为“未来可能会用到”就把所有工具都挂上去。工具越少，错误面越小。

4.2 全链路追踪：每个动作都要有回执

如果一个 Agent 执行了动作，但系统没有留下记录，那它就不适合处理有副作用的任务。我建议每个 Agent 调用都至少保留下面这些字段：

{ "trace_id": "agent_trace_20260120_0183", "request": "帮我查一下订单 A1001 是否可以退款", "parsed_intent": "order_refund_check", "model_version": "qwen2.5-72b-instruct", "context_snapshot": { "session_id": "ses_9901", "truncated": true }, "tool_call": { "tool": "order_query", "params": {"order_id": "A1001"}, "allowed": true, "cost": 0.002 }, "output": "该订单不符合退款条件，建议联系人工客服。", "human_review_required": false, "finished_at": "2026-01-20T10:00:03.218Z" }

这个结构就是一个最简单的执行回执。它不能保证 Agent 不出错，但它能保证出错之后有人能找到现场。

4.3 阈值熔断与人工审批

当 Agent 拥有写能力时，光靠权限还不够，要设置执行阈值。

常规思路是：单笔操作超过某个金额时暂停；一次执行涉及用户数超过某个数量时暂停；操作目标是删除、转账、发布、导入导出等危险动作时默认暂停；连续失败三次后停止，转人工处理。

这里不要一开始就把阈值拉高。先设置一个保守值，跑一段时间，看日志里的正常分布，再逐步调整。宁可多产生几次人工审批，也不要让一个错误批量扩散。

如果一个 Agent 的每个动作都查不到记录、挡不住危险操作、撤不回错误后果，那它买什么保险都只是在分摊损失，不是在减少风险。

4.4 可复现与可回滚

可复现的意思是，出错的会话要能回放。记录模型版本、采样参数、上下文截断策略、Prompt 版本、工具调用顺序。不要求百分之百复现模型输出，但至少要能还原决策路径。

可回滚的意思是，Agent 的写操作必须支持撤销。写入前先做快照，执行完留 undo 日志，不要直接覆盖原始数据。对于无法撤销的外部动作，比如发送通知、发布内容，只能靠前面的审批环节来拦截。

4.5 责任备案：一份可交给外部判定的记录

当 Agent 已经造成实际损失，团队内部需要形成一份责任备案，内容至少包括：现象描述、影响范围、定位链路、根因判断、是否可以复现、对应控制点、补偿方案。这有点像工程侧的保险单。

有了这份备案，对外可以回应质疑，对内可以把教训变成一个具体的回归用例，避免下次以另一种形式重现。

5. Agent 出错后，如何逐层定位责任

5.1 先给故障分类，不要急着改 Prompt

遇到 Agent 出错，最常见的错误是先怀疑模型，然后改 Prompt。更合理的方式是先给故障分类，再看是哪一层的问题。

如果你一上来就在 Prompt 里加“不要乱调用工具”，可能只是掩盖了一个工具注册和权限设计问题。

5.2 按链路逐层排查

我一般建议按下面的顺序走：

1. 先看用户输入。有没有诱导、歧义、缺失信息。
2. 再看意图识别和参数抽取。是工具选错了还是参数错了。
3. 再看 Prompt 组装。是不是把不该给的内容放进了上下文。
4. 再看模型版本和采样参数。是不是刚升级模型后出现的回归。
5. 再看工具调用参数。有没有超出合理范围。
6. 再看权限校验。有没有开启，是不是最小权限。
7. 再看输出校验。返回给用户之前，有没有过滤风险承诺。
8. 最后看日志。有没有 trace_id 能串起整条链路。

这个顺序的核心是：先确定是哪一层坏了，再决定修哪一层。不要跳过中间环节，一上来就怪模型。

5.3 要分清“模型错了”和“产品允许它错”

排查到最后，如果根因确实是模型幻觉，工作还没有结束。还要问一句：产品为什么允许这个幻觉变成一次真实动作？

比如 Agent 向用户承诺退款 20 元，可以拆开看：模型可能确实产生了承诺文本，但下游为什么没有校验“退款承诺需要权限”和“当前金额是否在允许范围”？如果没有输出校验，那产品在这个链路上就是有缺陷的。

“模型输出是概率性的”这句话，只能在排除了工程缺陷之后再说。否则，它就是在用模型的黑盒属性掩盖工程责任。

5.4 把错误变成回归测试集

出过一次错，就把这个场景放进 Agent 回归测试集。不要只放原始输入，还要放当时的上下文、模型版本、工具调用记录。每次改 Prompt、换模型、加工具之后，先跑一遍回归集再上线。

这一步是让 Agent 的可靠性从一次修复变成长期可持续的关键。

6. 工程能兜住“怎么错”，但兜不住“该不该做”

6.1 强监管和高价值场景：技术只是辅助，责任仍要落在有资质的人身上

在一些强监管、高价值的领域，Agent 即使技术上能做到自动化的程度，也不应该直接充当最终决策者。医疗诊断、法律意见、金融交易、行政审批、专利申请，都属于典型的例子。

拿“AI 辅助专利”来说，即使 Agent 能帮你做检索、生成初稿、梳理技术方案，最后负责的仍然应该是具有资质和经验的申请人或代理人。技术降低的是重复劳动，不是职业责任。

这里讲的不是技术能力问题，而是责任链问题。当前阶段，智能化辅助工具的定位更适合“人审机写”或者“机写人审”，而不是“机写机审”。

6.2 团队落地路线：从最小责任面开始

如果你正在考虑给自己的 Agent 增加工具能力，我建议按下面这个路线走：

• 第一个版本：只读 Agent。只允许查询和生成，不写库，不调用有副作用的外部工具。
• 第二个版本：开放低风险工具。绑定最小权限，并有完整日志。
• 第三个版本：允许有副作用操作，但必须有人工审批、阈值熔断和回滚机制。
• 第四个版本：才去考虑外部赔偿机制、责任险或保险产品。

这个路线的价值在于，每一步都能先验证“能不能控住风险”，再扩大能力边界。上线新能力之前，先问三个问题：Agent 做的每件事被追踪到了吗？错误路径能及时拦截吗？不可逆的错误能撤销吗？有一个“不能”，就不要急着放给用户。

每次给 Agent 放开一个新能力之前，都先问这三个问题。三个问题里有一个“不能”，就说明这个能力还不适合直接交到用户手里。

6.3 回到问题：Agent 要买保险，还是先要“可保性”？

回到标题里那个问题：Agent 也需要买保险吗？

我的答案很明确：需要，但不是先买保险，而是先具备“可保性”。

一个不可观测、不可记录、不可控制的 Agent，即使买了保险，也只是把损失从用户转移到了保险公司，社会总损失并没有减少。一个达到可保性要求的 Agent，哪怕暂时还没有外部保险，也已经通过日志、审计、权限和回滚机制降低了大部分风险。

保险从来不是第一道防线，而是最后一道兜底。真正值得投入的资源，是先让每个 Agent 动作可以被跟踪、被拦截、被撤销。没有这个基础，谈赔付、谈追责、谈用户责任，都是把一个工程问题抽成了口头争论，最后责任还是会落回信息最少的那一方头上，通常就是用户。

下次再有人问“Agent 是不是也需要买保险”，我可能不会先回答保险产品的问题，而是反问一句：你的 Agent 做的每一件事，能不能被看到、被拦住、被撤销？

如果能被看到、被拦住、被撤销，再谈保险不迟。如果不行，那它离生产环境还差得很远，更不应该让用户为这段距离买单。