企业官网建设流程全解析

大概从去年开始，我们团队接的Agent相关项目越来越多：让Agent帮用户查物流、自动整理周报、跑数据看板、甚至代为处理售后工单。项目多了之后有个现象特别扎心——同样的模型，Demo里跑得飞起，一上真实环境就拉胯。问题往往不在模型智商，而在我们压根说不清"这个Agent到底能摸到多远"。后来我给这套摸底和扩边界的方法起了个内部代号，叫Agent-Reach，直译就是"可触及范围"。这套东西说白了就三件事：怎么量化评估Agent的能力边界、怎么找到卡住边界的瓶颈、怎么用工程手段把边界稳着推出去。这篇文章把整套思路摊开讲，适合正在做Agent落地的同学，特别是刚被"Demo跑通、生产翻车"折磨过的人。

1. Reach到底是什么：别再拿单轮对话质量衡量Agent

1.1 一个让我改观的最小案例

先讲一个真实的最小案例。我们有个客服场景的Agent，早期验收只看"回答是否准确、语气是否友好"，所有评测都把这三项打得很高。可上线后发现，用户真正会问的是"我的订单显示已签收但我没收到，帮我查一下"。这个请求牵涉四步：识别用户身份、调订单接口、调物流接口、根据签收异常生成处理方案。我们的Agent在对话评测里拿高分，遇到这种多步操作却频繁断在第二步——因为它根本不知道该调哪个接口、参数从哪来。这个案例让我彻底意识到：对话质量只是表层，真正决定Agent价值的是"它能不能独立把一件事从a走到z"，也就是Reach。

1.2 Reach的三个构成维度

后来我把Reach拆成三个维度，方便团队对齐口径，也方便逐个诊断：

• 横向Reach（广度）：Agent能覆盖多少种不同类型的任务。常见问题是只能处理少数几个模板化请求，换一种问法就"听不懂"。比如用户说"帮我把这周销量拉个表"能触发，说"我想看看最近一周卖得怎么样"就触发不了。
• 纵向Reach（深度）：单个任务能走多深。一个任务最少需要几步工具调用？中间出现异常能不能自行恢复？用户诉求需要多轮澄清时能不能撑住不跑偏？
• 环境Reach（韧性）：在不完美条件下还能不能干活。比如接口超时、字段缺失、用户描述含糊、上游数据临时改了格式，这些生产环境的日常，才是真正的试金石。

这三个维度不是并列关系，而是乘数关系。横向再广，如果纵向只能做一层调用，实际能办的事还是很少；纵向再深，如果对环境变化毫无容忍度，放到生产环境几乎等于不能跑。我见过太多团队只盯横向Reach，拼命给Agent加功能描述，结果纵向和环境两个维度拖了后腿，整体交付能力依然没法看。

拿人来做类比最好懂：一个人在职场上能不能"办成事"，既看他认识多少人（广度），也看他能把一件复杂的事推进到什么程度（深度），还看他在突发状况下能不能稳住局面（韧性）。三个都到位，才是真正的高Reach。单轮对话评测就像"这个人会不会说话"，而Reach回答的是"这个人靠不靠谱、能不能托付"。

2. 量化Reach的实操框架：把"感觉还行"变成数字

2.1 从任务空间出发，而不是从模型出发

大部分团队评估Agent的方式是"拿几十个Prompt砸一遍，看回答像不像样"，这其实是在评估模型，不是评估Agent。评估Reach的第一步，是回到真实的任务空间：把一两个月内的真实用户请求全部捞出来，去重、聚类，得到一张任务清单。这张清单就是测试集的底本。

我当时做了一个特别土的统计：把客服系统的历史工单按"请求类型"和"完成路径长度"做成二维表。结果发现大量请求集中在六七种类型里，但每种类型的完成路径差异极大——有的两步完事，有的要跨五个系统。这直接决定了测试集该长什么样：每种任务类型必须有"简单路径"和"复杂路径"两个档位的样例，复杂路径里还必须埋上点异常。用这套办法生成的测试集，比随手写的几十个Prompt有效得多，因为它逼着Agent处理真实世界里那些不干净的情况。

2.2 四档评分：别用二值判断

我的另一个教训是：用"成功/失败"二值来判断Agent，会掩盖大量有价值的信息。一个任务，Agent可能自己完成了80%，剩下20%需要人接手；也可能每一步都对但用了五倍步骤；还可能在用户追问下才把信息补全。这些都不是简单的成功或失败。

我们最终定了四档评分：

这里有个关键细节：评分一定要基于过程轨迹而不是最终结果。我们后续开发了一个轻量的轨迹查看工具，每次评测都把Agent的工具调用链、中间决策、异常处理过程完整记录下来，评分员看着轨迹打档位，而不是只看最后那个回复。没有轨迹的评分，本质上是猜。

2.3 一次完整评估跑下来的样子

拿我们做的周报Agent举例。测试集有60条任务，分布在"拉数据、生成摘要、格式化排版、跨部门催办"四类里，每类各含简单和复杂两档。跑完一轮后我们拿到了一张表：

一眼就能看出瓶颈不在模型理解，而在"格式化排版"和"跨部门催办"这两块——前者卡在工具描述混乱导致选错模板，后者卡在Agent拿不到相关部门的最新对接方式。这两类问题靠换模型根本解决不了。这就是量化Reach的价值：把"感觉不稳"精确成"哪类任务、哪个环节、什么原因不稳定"。然后所有优化都从这张表出发，改一处测一轮，两周后同批测试集的S档比例从31%提到了67%。

3. 把Reach撑大的三个工程杠杆

3.1 工具层：描述即文档，文档即Prompt

工具是Agent的四肢，Reach的上限首先被工具层卡死。我见过太多团队急匆匆把API包装成function，名字起得敷衍、描述直接抄接口文档，还把大而全的方法塞成一个函数。结果就是Agent经常选错工具、填错参数、或者干脆不触发调用。

工具的打磨其实有很明确的章法。首先，每个工具只做一件事，粒度宁可小一点。比如"发送邮件"和"发送带附件的邮件"如果合并成一个工具，参数列表会爆炸，Agent在众多可选参数里迷失方向；拆开后每个工具的参数都很少，选错的概率直线下降。其次，工具描述要写清三个东西：这个工具解决什么问题、什么时候不要用它、关键参数的取值逻辑和常见坑。比如一个"查询库存"的工具，描述里要写明"仅适用于自营仓商品，第三方卖家的库存请走query_vendor_stock"，这两行描述能省掉后续无数错误调用。最后，所有工具的描述文本要纳入版本管理，工具变了描述必须同步变，否则Agent会一直拿旧描述去猜新接口。

我们内部有个不成文的规矩：工具描述每句话都要能回答"什么场景下该用它"或者"什么场景下不该用它"中的至少一个，不能写废话。实践证明，花两周时间把所有工具描述重写一遍，比换一个更强的模型带来的Reach提升更明显、更稳定。

3.2 上下文工程：系统提示、动态上下文和记忆的分工

第二个杠杆是上下文。一个常见误区是：把所有背景信息一股脑塞进系统提示，觉得"给Agent的信息越多它越聪明"。实际上上下文一长，Agent的注意力会被稀释，关键指令被淹没在无关信息里，这个现象我们内部叫"假饱和"——窗口没爆，但有效信息密度已经低到模型抓不住重点。

我的建议是把上下文分成三层。第一层是系统提示，只放稳定、高优先级的规则，比如任务边界、必须遵守的合规要求、输出格式。这段内容要短，尽量控制在几百字内，每句话都得是"删掉就会出问题"级别的。第二层是动态上下文，每次请求实时组装，只放跟当前任务相关的信息，比如用户资料、订单状态、相关历史记录，与本次任务无关的一律不放。第三层是记忆，分短期和长期：短期记忆记住当前对话里已经做过的事，避免重复操作；长期记忆沉淀用户的偏好和常见处理模式，但注入时同样只抽取和当前任务强相关的部分。每一层都有明确的写入和读取规则，上下文整体才可控，不会越滚越脏。

3.3 升级路径：该出手时就出手的人工兜底

很多团队把"人工介入"当成Agent失败的标志，这是另一个误区。成熟的Agent系统一定要设计显式的人工兜底通道，而且兜底不是事后补救，它应该是流程的一部分。

我们会在三个位置主动触发升级：一是置信度过低时，比如Agent对某个判断只有五成把握，与其硬着头皮往下走，不如直接问用户或转人工；二是操作不可逆时，比如删除数据、发送对外邮件之前，强制走确认环节，这个不能省；三是连续重试超过两次仍失败时，停止自动处理，把完整轨迹转给人工，不要让Agent在一个错误思路上反复打转。

这样设计之后，Agent的Reach反而变大了——因为它敢于尝试更多高价值任务，反正有兜底，翻车的代价可控。用户侧的感知也会更好：一个遇到难题主动说"这块我需要人工协助"的Agent，比一个硬编一个答案给你的Agent可信得多。

4. 实测翻车现场：三次完整排查链路

4.1 工具张冠李戴：为什么Agent老是选错工具

有一阵我们的数据看板Agent频繁选错工具。用户说"看一下华东区的销售趋势"，它不去调"query_sales_trend"，反而去调了"query_orders_raw"，结果返回一堆原始订单表，Agent自己都看懵了。

排查链路是这样的。第一步，打开轨迹记录，确认Agent在调用前确实"读过"两个工具的描述；第二步，对比两个工具的描述文本，发现问题出在格式太像——两个工具开头都是"查询销售相关数据"，连参数名都接近，"region"和"area"混用；第三步，做了一个小实验，把"query_sales_trend"的名字改成"query_region_sales_summary"，描述改成"按区域汇总销售额并返回趋势曲线，适用于销售趋势类问题"，同时把另一个工具的描述改成"仅返回订单级别的明细数据，不适用于趋势分析，字段多且未经聚合"；第四步，重新跑同批测试，选错率直接下降了一半以上。

这个案例告诉我们：Agent选工具的方式和人看按钮标签是一样的，标签模糊就一定点错。描述文本里的每一个词都在影响Reach。工具描述不是写给人看的注释，而是写给模型看的操作说明书，两者文体完全不一样。

4.2 "假饱和"导致的目标丢失

另一个更隐蔽的翻车：Agent在长任务中"忘了"最初目标。用户让Agent"对比去年和今年的营销活动效果，并给出三个优化建议"，Agent前两步都做得很好，但第三步输出时只写了两条建议，另一条被它自己"脑补"成了一个无关的运营观察。

排查后发现，问题不在模型，在我们。系统提示里塞了一份三百多行的数据字典，再加上用户历史偏好，真正关于"任务目标"的文字被挤到了很靠后的位置。模型每一步生成时，注意力更多落在靠前的数据字典字段名上，而不是用户的目标。修复方式很粗暴也很有效：把任务目标以"当前任务"区块的形式，在每次调用前重新注入到上下文最顶部，并且在每一步工具返回后追加一行"记住你正在完成的任务是：XXX"。这个改动看起来笨，但实测把长任务的目标保持率从61%拉到了89%。

4.3 权限边界的两难：管太死和放太开都是坑

权限设计是Reach里最容易被忽略、出了问题也最被动的环节。我们早期吃过一次亏：给Agent开了一个"查询全部客户资料"的接口权限，本意是方便它处理售后，结果有一次它在一个模糊请求下把一批不相关的客户资料也拉了出来，虽然最后没有外发，但合规团队脸色非常难看。

痛定思痛之后，我们不追求"最小权限"这种纸上谈兵的说法，而是做了两件事。一是按"任务-数据"矩阵来配权限：每个任务类型对应明确的数据字段白名单，比如售后任务只能读写"订单、物流、退款记录"，完全接触不到"合同、结算、客户分层标签"；二是给关键操作加"双保险"——Agent调用高敏感接口时，系统会检查这次调用的参数是否符合该任务类型的历史调用模式，明显偏离时直接拦截并要求人工确认。这两种做法落地后，权限越界事件降到了零，而且Agent的Reach没受影响——因为它需要的权限本来就在白名单里。权限设计的核心不是"给多少"，而是"给得是否有结构、是否可审计"。

5. 三个最容易被忽视的Reach杀手

5.1 指令噪声：系统提示每多一句，Agent就多一次跑偏的机会

指令噪声是我在所有项目里看到的最普遍的问题。产品经理今天加一句"回复要体现公司温度"，明天加一句"遇到不确定的先反问"，后天再加一句"注意合规"——每句话单看都对，合在一起就成了互相打架的指令集。Agent面对互相矛盾的指令，往往会选择其中"最响"的那句，而"最响"的往往不是你最在乎的那句。

我的经验是：系统提示里只保留四类内容——角色与边界、最高优先级规则、输出格式、升级条件。其他一切"应该注意的"内容，要么沉淀到工具描述里，要么放到动态上下文里按需注入，要么干脆删掉。每隔两周还要做一次"系统提示裁剪实验"：逐个删掉一句话跑测试集，如果指标没变化，这句话就是噪声，删了就对了。

5.2 中间状态不可观测：Reach最大的隐形天花板

Agent每走一步，系统里就多了一个中间状态。问题是很多团队只在最终输出上做文章，中间状态完全不可观测，Agent出错时只能看到"结果不对"，根本不知道错在哪一步。

我们在Agent-Reach体系里加了一条硬性要求：所有关键节点必须留痕。工具调用入参和出参、每一步的置信度、异常分支的触发原因、人工介入的位置和理由，全部结构化记录。这不仅是为了排查问题，更是为了建立持续优化的数据基础——没有轨迹，你连"Agent为什么Reach不够"这个问题都回答不了。每次评审会，我们看的不是成果展示，而是轨迹回放。

5.3 反馈回路延迟：Agent在等一个永远不来的确认

最后一个杀手是反馈回路的延迟。有些Agent设计成"每走一步都要用户确认"，美其名曰稳妥，实际上用户根本没有耐心一路点确认，结果Agent卡在中间等待超时，任务彻底中断。也有些Agent完全不要反馈，闷头跑完一个长流程，跑完了用户才发现方向和预期完全不符。

合理的做法是分层确认：低风险、可逆的步骤自动执行；中风险步骤在执行前静默展示"即将执行"的提示，用户不反对就继续；高风险、不可逆的步骤才显式等待确认。这套分层让反馈回路的"延迟感"大大降低，同时也保住了安全底线，Agent的纵向Reach因此能往上提一大截。

6. 推进这套方法的最小闭环

6.1 从小规模任务清单起步，先跑通再扩大

如果你也想在自己团队里推这套方法，我建议别一上来就搞大而全的评测平台，而是从最小闭环开始：先捞两百条真实请求，人工搓出一张任务类型表，再挑三类高频任务各写十条测试样例，跑一轮四档评分。整个过程一周内能完成，但你得到的不是一堆"感觉"，而是具体的瓶颈清单。有了清单，后面的优化就是按图索骥——该改工具描述就改工具描述，该调上下文结构就调上下文结构，该加兜底就加兜底，每改一处，重跑一轮，两周就能看到S档比例的明显变化。

6.2 关于指标口径的最后提醒

推进过程中最容易踩的坑是：不同的人对"完成"的理解不一致。所以四档评分的定义一定要落到具体例子上，最好在团队里组织一次"共同评分"的校准会，拿十条轨迹大家一起打档，把分歧摊开讨论。档位口径统一之后，Reach的量化才真正有参考价值，不然你只是在用一个看似精确的数字，记录一个实际上模糊的判断。

6.3 我的个人体会

Agent-Reach这套东西，说到底不是为了给Agent打分，而是帮助团队在"模型能力"之外找到真正可控的优化空间。我们内部现在有句糙话：别问模型行不行，先问系统让不让它行。工具描述写好了吗？上下文结构理顺了吗？中间状态能看清吗？人工兜底在哪？这些问题里的任何一个，都比"换个更大参数的模型"更能决定Agent的实际表现。

做Agent这一年多，我最深的感受是：Agent的边界从来不是模型画出来的，而是你愿意在系统设计上花多少心思画出来的。Reach不是天赋，是工程。