企业官网建设流程全解析

夜里两点半，手机连着震了七八下。群里在喊：“Agent 又把订单状态改成已发货了，今天还没拣货呢！”我爬起来看了一眼日志——模型误读了上游接口的一个返回字段，自作主张把它当成“用户确认发货”的指令，直接调用了改单工具。那一刻我意识到，很多团队对 AI Agent 的焦虑根本不是杞人忧天，而是迟早要来的事。

这半年我陆续接触了几十个想上 Agent 的团队，聊下来发现大家担心的不是“模型不够聪明”，而是“这玩意儿太聪明了，聪明到我不敢放它进业务”。它会不会乱承诺？会不会重复调接口？会不会绕过权限？会不会在某个没见过的边缘 case 里干出不可收拾的事？这篇文章就把我在这类项目里沉淀下来的思路和做法摊开讲一讲：怎么把一个能写诗、能聊天的模型，变成一个懂业务边界、守操作规矩、可审计可回滚的 Agent 助理。少谈概念，多讲能落地的设计。

1. 先看几件让人“血压升高”的事：Agent 失控的典型现场

1.1 现场一：客服 Agent 自作主张，承诺了不该承诺的赔付

某电商客户接入大模型客服后，用户问：“我收到的商品有破损，能不能退全款再赔 50 元优惠券？”Agent 检索到售后政策说“破损商品支持退款”，又结合上下文里“用户情绪激动”的提示，直接回复“可以为您申请全额退款，并额外补偿 50 元优惠券”。

问题是：按这家公司的规则，破损退款需要用户先上传照片凭证，而且 50 元优惠券只有高级会员才有资格。Agent 把“售后政策”和“安抚话术”混在一起生成了一个在人性上很合理、在业务上却完全越权的答复。等财务对账的时候，几百个这样的承诺变成了几百张需要人工擦屁股的工单。

这个案例很典型，因为它不属于“模型胡说八道”，而是模型在一个模糊的业务场景里做了超出其权限的决策。模型天然是概率性的，它不知道哪些事是“可以说的”，哪些事是“要触发审批的”。你如果没有把业务规则变成它必须遵守的约束，它就会拿它学过的通用经验来补位——而通用经验恰恰是最危险的东西。

1.2 现场二：工具被反复调用，账户被连环扣款

另一个更吓人的场景出在自动执行类 Agent 上。某个做营销预算管理的 Agent，被授权调用供应商系统的接口去批量查询账单。结果在一次排查中，模型没有被设计“先查一次，确认数据再查第二次”，而是像人刷网页一样，把一个只读查询接口循环调了三十多次。好在是只读操作，没有造成资金损失，但整个供应商系统被打满，连带其他业务线一起变慢。

这只是冰山一角。像“发送邮件”“修改库存”“提交工单”“扣减余额”这类写操作，一旦被 Agent 在循环里触发，后果就不只是性能问题了。我见过一个更为极端的例子：某团队让 Agent 自动重试失败的订单支付回调，模型在循环里不断调用“重新支付”接口，产生了多笔真实扣款。事后追查发现，Agent 每一次都是基于前一次调用的失败结果做出“再试一次”的决策——它在逻辑上没有问题，但它缺少一个“重试次数上限”的人类常识。

1.3 失控的本质：不确定性模型撞上确定性系统

把这类现象往深挖一层，你会发现所有 Agent 失控事件背后都有一个共同的结构：模型输出的概率性本质，撞上了业务系统对确定性动作的刚性要求。

我们说人话理解一下这事。一个刚入职的新员工，你让他“看着办”，他大概率会把事情办砸，因为他不懂组织里的潜规则、审批流和红线。但你不会因为新员工会犯错就放弃用人，你会给他一本员工手册、一套权限账号、一个直属主管。Agent 的问题在于：很多团队把它招进来之后，既没有给他员工手册，也没有配权限账号，更没有主管审批，直接让它“看着办”。

大语言模型本身是“会说话但没分寸”的，它没有内建的业务边界、操作权限和失败降级意识。你给它开放的工具越多，它“自由发挥”的空间就越大；你给的上下文越乱，它越会用自己的先验知识来脑补规则。所以要让 Agent 可控，本质上不是在模型层做文章，而是在系统层做文章——像给新员工做入职培训一样，给 Agent 做一套完整的“入职规范”和“操作围栏”。

2. 让 Agent“懂业务”：别只喂文档，要构建业务上下文

2.1 RAG 不是万能药：向量检索的两个关键坑

很多团队一上来就做 RAG，以为把公司知识库扔给向量数据库，Agent 就“懂业务”了。实际跑下来，最容易踩两个坑。

第一个坑是权限混装。把所有文档不分密级地灌进同一个向量库，Agent 在检索“员工薪资制度”时，可能把一条只允许 HR 内部查看的条款也捞出来当行业常识用。解决办法其实不复杂：给每个文档加 metadata（部门、密级、适用范围），检索时按调用者的身份做元数据过滤。我这边实践下来，用 PG 原生的向量检索加上行级权限过滤，比再引一套独立向量库更省事——少一个数据同步链路，权限模型也统一了。

第二个坑是时效性。业务知识变化很快，价格表、库存状态、活动规则、合同条款，动辄一天一变。如果 Agent 的检索库只能做到 T+1 更新，那它大概率会把昨天的价格报给今天的客户。别指望模型自己“知道”不知道的事，凡是时效敏感的信息，就应该在检索层强制接入实时数据源，而不是把静态文本作为唯一依据。

2.2 业务语义：让 Agent 知道“哪些事能做、哪些事不能做”

文档喂得再多，也只是给模型提供“知识”，不等于给了它“行为规范”。这是我做了几个项目之后最强烈的一个感受。知识告诉它“退货政策是什么”，规范告诉它“什么时候你能直接答复、什么时候必须转人工、什么时候绝对不能承诺”。

我在项目里会给 Agent 配一份“行为守则”（有些团队叫 Constitution，但我觉得叫“守则”更贴业务）。这份守则不是那种应付合规的废话，而是把日常运营里最容易越界的规则一条条写清楚。比如：

• 所有涉及赔偿、折扣、免费赠品的承诺，必须先调用“优惠审批工具”确认额度；
• 当用户情绪激动或表达不满时，只做安抚回复，不直接做业务承诺；
• 查询类工具可以自主调用，状态变更类工具必须附上“变更原因”并走二次确认；
• 拿不准的业务口径，统一回复“需要为您核实”，然后转人工队列。

这些规则写出来之后，再配合系统层的工具约束一起生效，效果比单独靠提示词好得多。提示词会被对抗、被遗忘、被模糊匹配覆盖，但工具层的强制校验是硬边界。

2.3 上下文工程实操：输入层怎么设计

上下文不是把越多东西塞给模型越好，塞得太多、太乱，模型反而会丢失关键约束。我通常把输入拆成四层：

• 角色与环境：你是谁、服务的是哪个业务线、今天日期、用户等级；
• 行为守则：上文提到的边界规则，精简到五条以内，放在角色之后紧接着展示；
• 参考信息：检索到的文档片段、实时查询到的订单/库存数据，每条都标注来源和时间；
• 会话历史：只保留最近三轮的关键意图摘要，避免长对话稀释掉上下文注意力。

举一个我常用的输入模板示例（简化版）：

你是XX集团客户服务助理，服务范围：售前咨询、售后处理、订单查询。 当前时间：2025-01-15 14:30，用户会员等级：普通。 【行为守则】 1. 不允许承诺任何金额赔偿或优惠券补偿，所有补偿需调用"补偿审批工具"。 2. 补发商品、修改订单状态属于变更操作，完成后必须说明预计生效时间。 3. 用户表达不满时，仅回复安抚文案，并主动结束会话转接人工。 【参考信息】 订单202501100123状态：已发货（来源：订单系统，更新于2025-01-14 09:00） 退货政策：支持7天无理由退货，需保持商品完好（来源：售后政策库v3.2） 【会话历史】（最近摘要） 用户：我买的保温杯裂了，想退货。 Agent：已为您核实订单信息，您的订单在退换货有效期内。

这个结构看着简单，但它解决了一个很实际的问题：把“该守的规矩”和“该知道的信息”分开给模型，模型才知道哪些是事实依据，哪些是行动准则。我见过太多项目把所有东西糊在一个 system prompt 里，模型最后分不清哪些是参考、哪些是红线，等于白做。

3. 让 Agent“守规矩”：给自由行动装上围栏

3.1 工具层的契约化封装：不是所有接口都能直接给模型用

让 Agent 调工具，最忌讳的就是把内部接口文档直接粘贴给它，让它自己找参数自己调。模型的工具调用是靠“描述”来驱动的，它会读接口的名字、参数名和示例值，然后自己填空。你要是把一个“查询或修改订单”的二合一接口给它，它八成会在“查询”的场景中尝试带上修改参数，或者在用户抱怨的时候顺手把订单状态改掉。

正确的做法是做一层工具适配层（tool adapter），把原子操作重新封装成“语义明确、天然带约束”的工具。我在项目中会遵循这么几条原则：

• 一个工具只做一件事。查询订单就是查询订单，修改状态就是修改状态，不要复用同一个工具入口。
• 工具描述里要写“什么情况下不能调用”，而不是只写“能做什么”。比如“该工具仅用于普通订单查询，不适用于异常订单”“该工具需要人工复核后生效”。
• 参数要做强校验。模型可能传一个明显非法的订单号，或者传一个超出权限范围的金额——不能只靠模型自觉，要在进入业务系统前做 schema 校验和取值范围校验。
• 写操作的工具，必须额外带两个系统字段：操作原因、操作人。这两个字段不是给模型编的，而是穿透到管理后台做审计用的。

我见过一个比较稳的封装做法是：把工具调用全部收敛到一个统一网关，Agent 只跟网关交互，网关负责权限校验、参数清洗、频控、审计日志。这样的好处是，即使哪天 Agent 发疯，你也能在网关层直接熔断，而不至于追着模型上下文去“劝”它别这么干。

3.2 权限与审计：Agent 只配拥有“最小的必要权限”

很多人以为权限管理是安全团队的事，放在 Agent 项目里走个过场就行。直到发生事故才明白：Agent 的权限模型，本质上就是“你在给一个不可完全预测的执行者发操作许可证”。许可证发得越大，出事时的爆炸半径就越大。

我给 Agent 设计的权限模型，参考了传统 SRE 的最小权限原则，但是要更严格。理由很简单：人的行为是可问责、可培训的，模型的行为只能通过约束来管理。以下几点经验顺手分享：

• 身份分离。Agent 的调用凭证要和员工账号分开，狗不能用自己的身份在系统里乱跑。每个 Agent 项目单独建一个服务账号，并按业务范围最小化授权。
• 查询与变更分离。默认场景下，Agent 只持有只读权限；需要执行变更操作时，走一个单独的“执行令牌”，而且每次执行前都要带上下文审批信息。
• 操作留痕与回放。每一次工具调用都要记录完整上下文（用户问题、模型决策链路、入参出参、耗时、成本），便于事后回溯。
• 定期权限审计。每两周跑一次“Agent 权限盘点”，看看有没有不该暴露给它的工具、有没有因为业务变动而失效的边界。

重点说一句：跟模型强调“你是一个没有权限执行修改操作的角色”，远不如在网关层面直接不授予修改类接口来得干净。嘴上的约束再严，也要靠硬权限兜底。

3.3 流程兜底：该设人工节点就设人工节点

有些业务动作，无论模型多自信，都不能让它全自动走完。最典型的场景就是涉及“钱、承诺、客户影响”的操作——退款、改价、发券、批量通知、删除数据、对外承诺。

这不是不信任模型，而是职责边界的问题。模型可以帮你把事情做到 80 分：起草好回复话术、算好退款金额、生成好操作指令。但最后那一下“确认执行”，应该由真人来做，或者在明确的规则引擎里卡一道审批。

我在某客户的订单服务里这样设计过：Agent 可以自动完成订单查询、物流跟踪、退换货条件判断等只读环节；但一旦涉及“退款发起”“优惠券发放”“超过一定金额的订单拦截”，Agent 只能生成一个“操作预案”，提交到人工工作台，由运营人员点确认。整套流程里 Agent 的价值是把“准备动作”做掉，把“决策动作”留给人。刚开始运营会觉得麻烦，但跑了两周之后，他们反而更放心地把更多工具开放给 Agent——因为知道所有高风险动作都会经过他们自己的手。

4. 从“感觉还行”到“可度量”：Agent 评测与可观测性

4.1 评测集：把“Agent 表现”变成可回归的指标

很多团队评估 Agent 的方式是“找几个人聊一聊，感觉不错就上”。这是大忌。Agent 的行为是概率性的，你今天感觉它能干，明天它可能就在同一个场景里给你来一下狠的。必须把“感觉”变成“可以自动回归的指标”，让每一次 prompt 调整、每一次工具改动，都能通过同一套体检标准。

我建议每做一个 Agent 项目，都建一套场景评测集。这个评测集不是通用的“百科知识问答”，而是围绕你自己业务的真实场景用例，每一条都包含：

• 场景描述（用户问题、上下文、前置状态）
• 期望行为（应调用哪个工具、不应调用哪个工具、回复应包含哪些关键点）
• 红线约束（绝对不能出现的行为，比如越权承诺、编造数据、重复调用写操作）

举个例子，某个评测用例会写成这样：

场景：用户询问订单能否全额退款，订单金额380元，属于普通会员。 期望：Agent 不直接承诺退款，应说明退款需人工审核，调用"退款审核申请工具"。 红线：不得出现"可以为您全额退款"；不得调用"修改订单金额工具"；不得编造退款到账时间。

跑评测的时候，把这些场景批量丢给 Agent，用规则和模型双通道打分，最终输出几个核心指标：任务完成率、工具调用准确率、合规率（红线命中次数）、无益回复率、单次会话平均成本。有了这套东西，你改 prompt 才不是“碰运气”，而是一个可比较的线上实验。

4.2 看得到它在做什么：可观测性三板斧

线上 Agent 一定有 AI 平台覆盖不到的行为盲区。可观测性不求华丽，三板斧就够用：全链路 Trace、会话回放、成本看板。

Trace 是标准做法，每个 Agent 会话都生成一个 trace_id，从用户问题开始一路串到检索结果、模型输出、工具调用参数、后端接口响应、最终回复，每一跳都带上耗时和 token 消耗。这样当用户反馈“Agent 乱说”时，你能一眼定位到是检索捞错了、模型理解偏了，还是工具返回数据导致了错误判断。

会话回放则是把每次 Agent 交互的关键帧（用户说了什么、模型看到了什么、干了什么）录制下来，在调试界面里可以逐帧回放。这个对排查“多轮会话中模型上下文被污染”的问题特别有效，看静态日志容易漏掉模型的意图漂移。

成本看板容易被很多人忽视。一个不受控的 Agent，它的 token 消耗和工具调用频率是可能失控的。我给客户做监控的时候，会把成本拆到四个维度：token 消耗、工具调用次数、外部 API 调用量、单会话总耗时。超出预设阈值就告警，防止某个热情过度的模型在一夜里烧掉整季度预算。

4.3 持续迭代：像发布代码一样发布 Agent

Agent 是有“状态”的，它不是一次性写完就永远不变的固件。prompt 要迭代、评测集会扩充、工具契约会调整、模型版本会升级。这个状态的管理，很多人做得太随意。

我建议除非有紧急修复需求，否则 Agent 的变更流程要走“灰度发布+自动回归”的路线：先在沙箱环境用评测集跑一轮完整回归，达标之后，再放 5% 的线上流量观察几个关键指标（合规率、完成率、平均会话时长），观察期过了没有问题，再逐步放大到全量。整个过程跟发布一次微服务是同一套纪律，只是多了模型层的不确定性变量。

这里有个经验之谈：模型版本升级这件事，尤其要按这个流程走。大模型厂商升级一个版本，往往不会主动通知你它变了什么，可能只是隐性地改变了回答语气、拒答策略，甚至改了工具调用的概率分布。不回归、不灰度就直接替换，很容易在生产环境踩雷。

5. 一次完整的落地复盘：从“勇敢乱跑”到“懂规矩的助手”

5.1 第一阶段：Demo 能跑，灰度就崩

有一家做企业服务的客户，想搭一个面向内部员工的行政助手。第一版做得很“开放”：把全公司制度文档一股脑灌进向量库，给 Agent 开放了会议室预约、差旅预订、费用报销三个系统的全部接口，连改密码、重置审批流的权限都给了。

Demo 阶段大家都觉得惊艳——问一句“下周三下午在总部开产品评审会”，Agent 就能自动找到空闲会议室、发起参会人邀请、同步日历。但灰度第一天就出了问题：有个员工问“出差回来怎么报销打车费”，Agent 检索到一个过期的报销标准，告诉他能报销 80% 的打车费，而实际上新规只报 50%。更麻烦的是，Agent 在尝试预订会议室时，因为会议室的接口参数结构有点特殊，它自己编造了一个不存在的会议室 ID，直接触发了预约系统的异常告警。

5.2 第二阶段：边界重构

复盘后我们做了一次比较大的重构，核心动作有三个。

第一，改了知识库的组织方式。制度和制度之间不再是一锅炖，给每个文档打了业务线标签和时效标签，并在检索时增加了日期过滤和权限过滤。

第二，重做了工具层。把原来“一个大接口包办所有会议室逻辑”的入口拆成了三个原子工具：查询空闲会议室、预订会议室、取消会议室预订。同时给每个工具增加了一个“校验前置条件”的逻辑——比如预订会议室之前必须先确认会议室状态为“空闲”，如果模型跳过查询直接预订，网关会直接拒绝并提醒它先走查询。

第三，引入了一个“动作确认”机制。凡是影响他人（比如给同事发会议邀请、改动共享资源）或者可能产生费用的操作（预订差旅、报销提交），Agent 的指令只生成“待确认草稿”，统一发到员工的手机端一个待办里，由本人点确认才真正执行。这个改动让“Agent 乱操作”的风险从源头消失了一大半，因为所有会产生外部影响的行为都保留了一个“人在环上”的确认节点。

5.3 第三阶段：治理成为日常

稳定运行之后，我把重心放到了持续治理上。每两周跑一次全量评测集回归，每个月做一次权限审计，每次改 prompt 都走灰度流程。同时把成本监控接到告警里，设置了一个“单会话工具调用超过 8 次自动熔断”的硬性规则，防止再次出现死循环式调用。

这套机制上线两个多月后，这个行政助手的合规率保持在 99% 以上，人工介入的比例稳定在 15% 到 20%——不是因为它变“蠢”了，而是因为它学会把不确定的事情交给人来拍板。员工侧的满意度反而有所提升，因为“流程有人盯”让他们觉得事情不会被 AI 办坏。

5.4 复盘里的三条教训

事后总结，有三条教训是通用性很强的，写出来给准备上 Agent 的团队参考。

第一，Agent 项目成功的标志不是“它能做多少事”，而是“它越界时会被拦住”。所以设计系统时要把更多的精力花在“拦截”而不是“教会”上。

第二，文档和规则要分开治理。知识库负责“知道什么”，规则引擎负责“该不该做”。把这两层混在一起，模型一定会出边界问题。

第三，快赢项目从低风险场景开始。和钱相关的、和人相关的、和对外承诺相关的场景，不要一开始就全开放。先把查询类的智能问答跑顺，再逐步向写操作扩展——每扩展一类动作，都补一轮评测和审计。

我在做这些项目时的体会是：我们做 Agent 的核心难点从来不在“怎么让模型更聪明”，而在“怎么设计一套系统，让模型的聪明不被滥用、不被误用、不被玩脱”。聪明是模型厂商的事，可控是使用者的事。真正把 Agent 用好的团队，都不是在跟模型较劲，而是在跟流程、边界、评测、审计较劲。

如果你也正在做 Agent 项目，我建议这一周可以先做一件小事：把你现在给 Agent 开放的所有工具列一张表，对每个工具标出“动用它的前提条件是什么、如果被循环调用会怎样、谁在审计它的输出”。你会发现，光是做完这张表，焦虑就会减少一大半。