企业官网建设流程全解析

这篇文章不是讲方法论，而是想复盘一下：一个原本只是给内部业务包一层MCP接口的"套壳项目"，怎么在三个月里一步步变成了一个带研究、分析、决策辅助能力的完整系统。中间没有大的架构预谋，每一步都是被真实需求推着走，回头一看，这玩意儿已经不是当初那个壳了。

如果你正在做MCP服务开发、AI工具集成，或者在一个老系统上接AI能力，这篇文章里记录的演化路径、模块拆分、踩坑细节，应该能帮你少走不少弯路。不废话，直接开始。

1. 先别笑：为什么"套壳MCP"会是一个真实需求

1.1 这里的"套壳"指的是什么

MCP（Model Context Protocol，模型上下文协议）是一个把AI模型和外部工具、数据源连接起来的开放协议。它定义了一套标准的工具调用、资源访问和上下文传递方式，让AI应用可以像一个统一插线板一样，插上不同的MCP工具就能干不同的事。

而"套壳MCP"在实操中通常指：在一个已经存在的业务系统或者一堆散装脚本之上，包一层标准的MCP服务接口，让AI助手能够调用它。说得直白点，就是把老系统的能力，翻译成AI能听懂的话，然后开一个门让AI进来干活。

这个需求听着不性感，但现实中极其普遍。因为大部分团队的老系统改造起来成本高、风险大，更不可能推倒重来。MCP恰好提供了一个低侵入的切入点：你不需要改老系统的内部逻辑，只需要在外面加一个适配层，把老系统的输入输出转换成MCP能识别的工具调用格式，就完事了。

我们当时的情况也差不多。某团队内部的业务系统已经跑了很多年，数据都在里面，但查询入口非常老旧，团队成员想临时看个指标都得找特定的人帮忙跑数据。我们就琢磨着，能不能包一层MCP，让AI助手直接对接这些数据查询能力。

1.2 最初的需求清单其实很朴素

项目刚启动的时候，需求就三个：

• 自然语言查数据：团队成员用对话的方式，查询项目进度、资源占用、关键指标等常规数据。
• 报告汇总：把散落在多个文档里的日报、周报信息抓取出来，按模板生成汇总报告。
• 阈值提醒：监控几个核心指标，超过设定阈值时自动推送提醒。

这三个需求拆开来看，每一个都很轻。自然语言查数据，本质是一个MCP工具加上查询解析；报告汇总，就是文档读取工具加模板渲染；阈值提醒，最多加一个定时任务扫描工具。我们一开始也确实是这么设计的，三个工具，一个统一入口，一个MCP服务，完事。

按当时的时间估算，这个壳子大概一周就能搭完。事实也差不多，骨架确实一周搞定了，但噩梦从第二周开始。

1.3 用户预期的第一次膨胀

壳子跑起来之后，团队里的人新鲜了两周。每天用自然语言问数据、让AI汇总报告，确实比原来翻系统快多了。但很快，问题就变了。

原话我记得很清楚："数据查出来了，但是能不能帮我分析一下为什么这个指标降了？""这几份报告汇总好了，能顺便告诉我目前哪个方向风险最大吗？"

一开始我们的态度是：不行，这是个查询工具，不做分析。但问的人多了，我们自己也意识到，如果拒绝这个需求，用户就只能自己把数据拷出去，再丢给大模型问一遍，然后再把结论拿回来。这个流程极其断裂，用户体验很差。

那时候做了一个极其重要的决定：不是把分析能力硬塞进现有的MCP工具链，而是在工具调用之上加一层"任务编排"能力，让系统可以按顺序调用多个MCP工具，中间穿插数据处理和推理步骤。这个决定的后果，直接决定了后面系统会走向哪里。

2. 三个演化岔路口，决定它不再是"壳"

2.1 第一次演化：从工具封装到任务编排

MCP协议本身解决的是"AI怎么调用单个工具"，它不解决"AI怎么按正确顺序调用一堆工具、中间失败了怎么处理"。当你只有一个查询工具的时候，不需要编排。但当分析需求出现后，整个流程就变了。

以"为什么指标降了"这个问题为例。要回答它，至少需要三个步骤：先把相关指标的历史数据拉出来，再把同期其他指标的数据做对比，最后结合业务变化记录做归因分析。三个步骤涉及的工具是一样的，但顺序、依赖关系、数据传递方式，都需要一个调度层来管理。

当时我们调研过一些工作流引擎，但都太重型了。考虑到这个系统本身是从"壳"起步的，我们选了一个轻量方案：自己实现一个简单的有向无环图（DAG）调度器。每个任务节点可以是MCP工具调用、数据处理函数、或者模型推理步骤。节点之间通过一份统一的上下文协议传递数据。

这个调度器在代码上其实不难，难的是设计"节点输入输出"的格式规范。我们定了三条规则：

• 每个节点的输出必须是结构化JSON，不能是自由文本；
• 节点之间通过显式的字段引用传递依赖，不允许隐式共享内存；
• 任意节点失败时，如果要降级，必须走预设的fallback路径，而不是让模型临场发挥。

这三条规则后来成了整个系统稳定的基石。等系统长成完整的决策框架之后回头看，这次演化的意义不只是"能跑多步流程"了，而是让系统第一次具备了"研究"的基本形态：先收集数据，再分析数据，最后输出判断。

2.2 第二次演化：从单次问答到证据链闭环

第一次演化让系统能做多步操作，但它仍然是一个"黑箱"：用户问了一个问题，系统转了半天，吐出一个结论。至于这个结论是根据哪些数据得出来的、经过了怎样的推理过程，用户完全不知道。

在业务场景里这是不可接受的。因为就算AI的分析结论有道理，团队也不敢直接采信一个没有出处的判断。毕竟是拿来做管理决策参考的，错了要背锅。

于是我们做了第二个关键决定：引入证据链机制。

具体方案是：系统每次执行研究任务时，会自动记录三样东西——原始数据快照、中间节点输出、最终结论。这三样东西通过一个traceID关联，每次用户提问都会自动生成一个独立的研究档案。用户不仅能看到结论，还能一层层点开，看到某条结论是由哪几个数据点支持、经过哪个推理节点得出的。

听起来容易，做起来有不少细节。最核心的困难是：模型在推理过程中产生的中间结果是不稳定的，同一个问题不同时间问，中间步骤可能有差异。如果我们只记录最终调用的工具和数据，证据链就只是个日志，对用户没有实际意义。

我们的解法是给调度器增加"步骤级标注"功能。每当DAG中的一个节点执行完，调度器会强制把节点输入和输出摘要写入证据链，同时在模型做推理前，调度器会把之前的关键数据摘要注入到模型提示词里。这样就能保证一件事：不管模型怎么发挥，它的最终判断一定是基于证据链里已经记录的数据，而不是它自己脑补出来的内容。

这次演化让系统从"回答者"变成了"研究者"——它不是给你一个答案，而是给你一份可以审查的研究报告。很多内部用户开始信任这个系统，就是从证据链功能上线之后开始的。

2.3 第三次演化：从被动应答到主动监控

前面两步演化之后，系统已经能处理相当复杂的研究型问题了。但它仍然是一个"你问它答"的工具。如果没有人提问，系统就静默待命，什么也不做。

转机出现在一次具体的事故上。有一天，一个关键指标突然异常下降，但因为没人主动去查，系统毫无反应。直到晚上复盘会议，才发现问题。

这次事故后，产品负责人提了一个要求：系统应该主动盯指标，而不是等着被问。

这次的改动比前两次都要"出圈"，因为系统不再只是一个MCP服务了，它还需要在后台持续运行、感知外部变化。我们做了一套事件驱动机制：

• 定时任务按照预设频率扫描关键指标，生成指标快照；
• 快照与历史基线对比，偏差超过阈值则触发分析流程；
• 分析流程自动复用已有的DAG调度器，生成归因报告；
• 报告生成后，通过消息服务主动推送给相关人。

这个机制上线后，系统才真正成为"决策系统"的一个完整雏形：它能主动发现问题、分析问题、输出建议、送达相关人员。整个链路不再是"人发起、AI响应"的单向关系，而是"人机协同"的双向互动。

3. 研究决策系统的关键模块拆解

到这一步，系统已经从"套壳MCP"长成了一套完整的决策辅助框架。下面把系统的关键模块做一个拆解，每个模块我们踩过的坑、最后定型的设计方案，都一并讲清楚。

3.1 统一数据访问层：MCP工具背后的数据底座

很多人以为MCP工具就是直接查数据库，其实不是。如果每个MCP工具都直连各自的库、各自的表，那调度层就没法统一管理了。我们花了很大力气做的是：所有MCP工具背后，必须通过一层统一数据访问层，不许直接连底层数据。

这个数据访问层分了三层结构：

• 原始层：底层业务系统的数据，表结构、字段命名都很随意，直接暴露给模型是不可控的。
• 汇总层：对原始数据做清洗、去重、格式化处理后形成的宽表，按业务主题组织。
• 指标层：进一步把宽表加工成指标，比如"日活转化率""渠道成本占比""库存周转天数"。这一层是MCP工具直接读取的对象。

MCP工具只读指标层，有几个好处：数据口径统一，权限控制简单，模型不会接触到底层脏数据。

指标层的索引和缓存是我们踩过最多坑的地方。一开始没有做缓存，每次用户提问都去汇总层现算，一个指标动辄几千万行数据，查询动辄几秒到几十秒。后来加了二级缓存：结果缓存（同一个问题短时间内的重复查询直接走缓存）和预聚合缓存（提前算好常用指标，查询时只做时间维度裁剪）。缓存上线后，系统平均响应时间从8秒降到1.5秒左右，体验完全是两个量级。

还有一个细节容易被忽略：MCP工具的输入参数设计很重要。我们要求工具的参数表结构必须是"时间范围 + 业务维度 + 指标ID"的形式，这是为了后续任务编排时，不同工具之间可以方便地共享参数。如果每个工具的参数格式各搞各的，调度器做参数传递的时候会痛苦到怀疑人生。

3.2 决策规则引擎：别把全部判断都交给模型

在搭建过程中，我们最坚持的一个原则是：别把一切都押在模型推理上。对于确定性强的判断，应该用规则引擎来处理；只有开放性问题才交给大模型。

举个例子，"某指标本周环比下降超过10%"这个判断，你完全不需要大模型。写一个简单的阈值判断，准确率100%，响应时间1毫秒。如果非要把这个判断也丢给模型，不仅慢，还有可能因为模型输出的不确定性导致误判。

我们的决策规则引擎归为两类：

统计规则：基于数学公式的确定性判断。比如环比变化率、同比变化率、三日移动平均线突破、方差异常检测。这类规则全部用代码实现，不走模型。

语义规则：基于业务知识的经验性判断。比如"当获客成本上升且留存率下降同时出现时，判定为增长结构恶化"。这类规则也需要用结构化规则表达语言配置，而不是让模型自由发挥。

只有一种情况我们会主动调用大模型：当规则引擎无法穷举候选原因，需要基于文本信息做开放性推理的时候。比如"请根据过去两周的运营日志和竞品动态，给出转化率波动的综合解读"。

这种混合决策架构有一个非常直观的好处：系统的决策过程是可解释的。用户问"为什么系统认为这个渠道效率低下"，我们可以立刻给出答案：因为该渠道的获客成本指标连续七天超过阈值，且同期的用户留存率下降超过了5%。每一个判断都有据可查，用户自然愿意信任系统。

如果你把全部判断都交给模型，那你就得接受一个现实：系统做出的每一个判断都可能出现模型幻觉，而你几乎没有成本低的手段去验证。

3.3 上下文压缩与记忆管理

研究决策系统一个最容易被低估的难点是上下文管理。系统在执行复杂任务时，往往会在多个节点之间传递大量数据。如果每个节点都把全量数据返回给模型，模型的上下文窗口很快就会被打爆。

我们采取的是两级压缩策略：

第一级是结构化摘要。每个工具执行完毕返回数据时，数据访问层会自动生成一个摘要对象，包含：涉及的时间范围、数据总量、最大值、最小值、均值、主要趋势变化点。摘要对象体积很小，几百字节以内，模型只需要读摘要就能把握全局。

第二级是关键字段截断。有些业务场景下，模型确实需要看到原始明细数据，比如找出某个异常值所在的维度。这种情况下，我们会让工具可以按需加载明细，但只加载当前推理步骤真正需要的字段，并且限制返回行数（一般是前50行或者按相关性排序后的TOP N）。

记忆管理方面，我们最初做得很朴素，就是直接把多轮对话拼进提示词，结果长任务跑到一半，上下文就乱了。后来参考了比较成熟的记忆管理方案，把系统记忆拆成了两层：

• 短时记忆：当前研究任务内产生的数据摘要、中间结论、引用来源。任务结束后清空。
• 长期记忆：跨任务保存的稳定信息，比如用户的业务偏好、常用的指标口径、反复出现的数据异常记录。长期记忆经过摘要化之后，只保留最有价值的部分。

这里有一个非常容易踩的坑：如果你只做摘要，不做剔除，长期记忆会快速膨胀。我们的做法是给长期记忆内的每一条记录加一个"使用频率"字段，超过一定时间没有被调用过的记录会自动归档降级。相当于给记忆做了个LRU缓存。

3.4 审计与回放机制

研究决策系统跟纯工具型的系统不同，它输出的内容是决策支持信息。既然涉及到决策，就必须能审计、能回放。

我们给系统中的每一个研究任务分配一个全局唯一的traceID。这个traceID贯穿整个链路，包括入参、调度器执行过程、每个节点的输入输出摘要、模型推理日志、最终结论、以及主动推送记录。

回放机制做得比较彻底：在系统的后台管理页面，可以按traceID查询某个历史任务，看到完整的执行链路。每一步用了哪个工具、查了哪些数据、中间推理的过程文本是什么、最后结论是怎么生成的，全部可查。

这项能力上线之后，产生了一个意外的副产品：它变成了我们排查系统问题的第一利器。以前，发现系统给了一个错误结论，只能靠复现问题来定位；现在直接在后台看证据链，是数据错了、工具挂了还是模型胡扯了，一眼就能定位。

还有一个细节：审计日志的记录时间最好用系统统一时钟，不要依赖各服务器的本地时间。我们有段时间大量使用容器部署，各实例的时钟偏移导致日志时间线错乱，排查问题的时候极其痛苦。后来统一接了一个时间同步服务，这个问题才算根治。

4. 实操过程中遇到的坑和解决方案

4.1 工具描述写得太模糊，模型开始瞎猜

MCP工具的描述信息直接决定了模型能不能正确选择和使用工具。刚开始写描述时，我们偷懒了，每个工具就一两句话，比如"查询业务指标"，完了。

后果是灾难性的：模型经常不知道选哪个工具，也不知道该传什么参数。比如系统里有两个工具，"查询渠道指标"和"查询整体指标"，模型分不清"渠道"和"整体"的区别，经常传错维度值，返回空数据时它也察觉不到。

后来我们花了整整一个下午，把每一个工具的描述按照一个固定模板全部重写：

• 这个工具是干什么的，适合什么场景；
• 不适用什么场景，什么时候应该用另一个工具替代；
• 完整参数列表，每个参数的类型、取值范围、默认值；
• 一个具体的调用示例，包括输入和输出；
• 返回数据的结构说明，以及可能出现的空值情况。

重写后，模型选工具的准确率明显提升，而且有个意外收获：因为描述写清楚了"什么时候不该用"，模型在条件不足时会主动说明原因，而不是硬着头皮调用一个不合适的工具。这一点对研究决策系统的严谨性非常重要——有时候答不上来比胡答要好得多。

4.2 MCP调用超时与重试策略

MCP工具调用外部API的时候，网络抖动、服务繁忙、数据量大，都可能导致超时。最开始我们没管这个，结果模型经常一调用工具就收到一个"timeout"错误，然后它就认为这个工具不可用，转而去编造一个听上去合理的答案，或者直接放弃。这个问题的隐蔽性在于：模型并不会明显表现出"因为超时所以我放弃了"，它通常会假装完成了任务，然后给一个模糊的回答，很多用户就被糊弄过去了。

我们的解法是分级设置超时策略：

• 快速工具（如简单的指标查询）：3秒超时，重试1次；
• 中速工具（如带汇总计算的数据查询）：10秒超时，重试2次；
• 慢速工具（如跨多系统数据对比）：30秒超时，不重试，直接降级为人工处理。

这里有一个细节值得写出来：重试不是简单的同一个请求发两遍，而是要在重试前做一个幂等性判断。如果这个工具调用产生了副作用（比如写入数据），重试就会导致重复执行。我们在设计MCP工具接口时，强制要求写操作工具必须支持幂等标识符，查询类工具天然幂等，这个问题就提前规避了。

还有一个容易忽视的地方：工具超时后，调度器给模型的错误信息必须明确。不能只写"调用超时"，而要写清楚"工具查询了多长时间、包含哪些参数、下一步建议是降级还是等一会再试"。这样才能让模型在失败时做出合理的应对，而不是慌不择路地编答案。

4.3 长任务与流式输出的配合问题

研究决策系统有些任务执行时间很长，动辄几十秒。问题在于：模型发出工具调用请求后，通常会在几秒内等待结果。如果工具迟迟不返回，模型端的逻辑就会出现真空期，表现得像"卡住了"。

这里我们试验过两种方案。第一种是让MCP工具尽快返回一个"任务已接收"的确认结果，然后让系统内部异步执行真正的流程。第二种是采用任务ID加进度回调的方式，模型拿到任务ID之后，可以轮询或订阅进度。

最终我们选了第二种，因为它更自然。流程是这样：

• 模型调度器发出请求，系统立即返回一个researchTaskId；
• 系统后台开始执行DAG流程，每个节点完成时更新进度状态；
• 模型每隔一段时间调用一个"查询任务进度"的工具，获取最新的任务进度和前序节点的结果摘要；
• 整个过程结束后，模型再调用一个"获取最终结果"的工具，拉取完整的结论和证据链。

这套方案上线后，长任务不再显得"卡死"，模型可以在任务执行期间给用户输出阶段性的反馈，比如"我已经完成了数据采集，正在分析三个候选归因，预计还需要10秒"。这个细节对用户体验的影响极大，因为用户能感知到系统正在工作，而不是干等。

4.4 权限与数据脱敏的复杂度

研究决策系统一旦联动到真实业务数据，权限问题就会立刻浮出水面。不同角色能看的数据范围不一样，如果不做隔离，后果非常严重。

我们最终把MCP工具分成了三层权限控制：

• 调用权限：谁可以调用这个工具。比如普通成员只能调用查询类工具，管理者才有权限调用导出和写入类工具。
• 参数权限：同一个工具，不同人能看到的数据范围不同。比如区域经理只能传自己区域的维度值，传其他区域会直接报错。
• 结果脱敏：部分工具返回的数据要经过脱敏处理，屏蔽掉手机号、身份证号、内部备注等敏感字段。脱敏放在数据访问层做，不在MCP层做，这样不管什么入口触达数据，脱敏逻辑都能生效。

这里有一个很关键的教训：权限判断一定要做在服务端，而不是依赖模型去判断该不该调用某个工具。因为模型非常容易被绕过，你告诉它"某某人没有权限"，它可能会想方设法换一种方式去问，比如换个措辞重新描述工具参数。

另外，权限策略要定期review。我们在上线初期，给一个查询工具设置的权限范围偏宽，结果有人在对话中查到了其他部门的数据，虽然没有出事，但这一事件瞬间让团队对权限重视程度上了几个台阶。

5. 现在这个系统能做什么：能力边界与落地效果

5.1 一个完整的研究决策链路示例

用我们最核心的一个业务场景来演示一下现在的系统能力上限。

假设业务负责人问："过去一个季度，我们的转化效率在哪个环节下降最明显？"

系统收到这个问题后，整个执行链是这样跑的：

第一步，意图识别和方案生成。模型分析出这个问题需要做"分段效率分析"，于是生成一个包含四个节点的DAG：拉取线索阶段的数据、拉取销售跟进阶段的数据、拉取成交阶段的数据、拉取各阶段转化率变化。

第二步，调度器执行DAG。四个节点分别调用MCP工具查询指标层数据，每个节点返回时，调度器自动生成结构化摘要写入证据链。

第三步，异常筛选与归因候选。规则引擎先做统计判断，计算各阶段转化率的环比变化率，锁定了"销售跟进阶段转化率从上一季度的23%下降到17%"这个显著变化。然后模型基于运营日志和团队会议记录等文本数据，生成三个候选归因：跟进时效下降、线索质量下滑、话术调整后转化率波动。

第四步，结论生成与证据链整理。模型综合量化证据和文本证据，输出结论："主要下降集中在销售跟进阶段，初步指向线索响应时效从2小时延长到6小时后转化率同步下滑，建议优先排查响应时效。"同时，系统自动附上了响应时效与转化率的时间序列对照数据作为证据。

整条链路运行下来大约是25秒，用户获得的不只是一个结论，还有完整的证据路径。可以直接把这份报告转发到复盘会，不需要再手动整理。

5.2 能力边界：系统不能做什么

尽管系统做到了上述程度，我们还是清醒地知道它的能力边界在哪里。

第一个边界是深度归因。系统可以给出候选归因并排序，但它无法像资深分析师那样，基于多年经验、行业认知和对业务细微变化的感知，做出深度的因果判断。比如"某个渠道新增了一批高价词导致转化率虚降"，这种洞察需要人对业务上下文非常熟悉，系统目前只能提供可能性提示，最终定性还是需要人来判断。

第二个边界是数据质量。系统再聪明，也是建立在数据质量之上的。如果原始数据存在大量缺失、错误或口径不一致，系统产出的结论就会出现偏差。我们在实际使用中遇到过几次这样的情况：指标层的数据清洗逻辑升级后，导致历史口径不一致，系统给出的同比结论明显失真。后来我们在证据链里加入了"数据质量标记"，当系统检测到某指标的可信度低于阈值时，会在结论中主动提示"该结论基于不完整数据，仅供参考"。

第三个边界是突发未知事件。系统擅长在已知的维度里做分析，但对于完全无法预知的事件（比如突发的市场变化、意外的人事变动），它只会把这些作为"异常文本"记录下来，很难自行建立因果关系。这种时候，系统的价值更多是及时暴露异常，而不是解释异常。

明确边界有一个非常重要的好处：使用者的信任度会更高。如果你试图让系统包打天下，用户会在某一次失败后立刻失去信心。如果系统清晰地标出哪些事情它能做好、哪些不能，用户就会在能力范围内放心地使用它。

6. 关于"长成"的反思：架构演化的启示

6.1 为什么一个壳会长成系统？因为数据闭环跑通了

回到标题的问题："一个套壳MCP，为什么长成了研究决策系统？"如果用一句话回答：因为套壳之后，数据闭环跑通了。

闭环的起点是用户需求。套壳最初只是让AI能调用数据，但用户接着就会说"帮我分析"，于是你要加编排；要分析就得有依据，于是你要加证据链；分析完了用户还会说"盯紧点，别等我问了才告诉我"，于是你要加主动监控。每一步都是为了把这个闭环的某个缺口补上，补着补着，它就长成了系统。

这个过程不是规划出来的，而是被使用逼出来的。所以如果你发现自己手头有个项目正在经历类似的演化，我的建议是：**不要抗拒演化，但也不要无脑膨胀。**每一步都要想清楚，这次增加的能力是否补上了闭环的某个缺口？如果答案是肯定的，就放心去做；如果只是为了"显得强大"，那多半是不必要的。

6.2 演化过程中最该坚持的三件事

回顾整段路程，有三件事我们从头到尾都没有妥协过，现在看是极其正确的坚持。

第一件是可回放。所有研究任务都必须有traceID，所有结论都必须有证据链。这件事在最早期做成本很低，但如果等系统复杂之后再补，几乎不可能补上。你可以没有精美的界面，但你不能没有追溯能力。

第二件是可降级。系统里的每一个关键路径，都必须有降级方案。MCP工具挂了怎么办？数据访问层返回超时怎么办？大模型调用失败怎么办？我们为每一项都准备了降级路径，确保系统在故障时不是直接崩掉，而是以更低的能力水平继续服务。运行半年多来，降级路径被触发过很多次，每一次都避免了严重的线上问题。

第三件是可解释。系统的每一步决策逻辑都应该是人能够理解的。我们尽量避免把所有逻辑都塞给模型做，而是用规则引擎处理确定性问题，用模型处理开放性问题。这样的系统也许不如"全用模型驱动"看起来炫酷，但它的行为是可以被理解的，是可以被修正的。对一个实际用于业务决策的系统来说，这比任何花哨功能都重要。

6.3 什么时候应该主动踩刹车

系统演化不是单行道，不是所有功能都是越多越好。我们中间也走过一段弯路：有一阵子我们觉得既然系统有分析能力，不如把方案推荐、项目规划、甚至人员绩效评估也塞进去。后来在一次模拟测试中发现，系统在绩效评估上给出的建议是极度片面的——它只看到了量化指标，完全忽略了很多无法量化但同样重要的因素。好在我们在上线之前踩了刹车，把这类过于主观的决策功能全部砍掉了。

从那以后我们定了一个规矩：**任何新增能力，必须回答清楚"系统在这个任务中扮演什么角色、人类保留什么决策权"这两个问题才允许进入开发。**如果角色的边界模糊，或者人类决策权无法清晰保留，那这个能力再酷也不上。

这不是保守，而是对系统负责。因为研究决策系统的最终价值，不是替代人类做决策，而是把人类做决策所需的信息、证据、推理过程整理到最清晰的状态。这种定位，越早想清楚越好。

做完这套系统之后，我有一个比较深的体会：很多"大系统"不是一开始设计出来的，而是在持续服务真实需求的过程中，一层一层长出来的。你不需要一开始就想清楚最终形态，但你需要在一开始就把那些将来会增加成本的基础能力（比如可审计、可回放、可降级）想好。这些能力在系统只有三个工具时做，只要一下午；在系统有几十个工具时再做，可能就是好几周甚至几个月的工作量了。

我们算是运气好，在还来得及的时候做了对的选择。如果你正在做类似的东西，以上这些路径和教训，应该能给你一个参考。