企业官网建设流程全解析

先交代一下背景。我在某公司负责一个面向客户服务的AI Agent项目，上线的第一个版本效果还不错，但跑了一个月之后就发现问题越来越明显：User问法稍有变化就答错，同类问题反复出现，运营同学每天手动把坏case发到群里，我们改完Prompt发版，过几天又冒出新问题。更让我难受的是，用户其实一直在“教”它——有人把正确答案重新输了一遍，有人点了踩之后又手动复制了正确答案，有人明确说“你不对，应该是XXX”。这些反馈全部散落在日志里，没有任何机制把它们送回到模型和Prompt的迭代中去。

这就是所谓“静态Agent”的典型困境：模型权重和Prompt在你部署的那一刻就冻结了，用户产生的海量修正信息被白白丢弃。后来我花了大半年时间，把整个流程改造成了一套“反馈采集 → 数据分析 → Prompt优化 → 模型微调 → 回归验证 → 灰度发布”的闭环机制，也就是标题里说的“AI Agent Harness Engineering 自我进化机制”。这篇文章把我实际落地的流程、踩过的坑、以及每一步背后的判断标准完整写出来，希望能给正在做同类事情的团队一些可参考的路径。

1. 为什么Agent需要一套“自我进化”机制：静态系统的死穴

1.1 Agent和传统软件的本质差异：错误是常态而不是Bug

传统软件工程的假设是：只要输入确定、逻辑确定，输出就是确定的。你可以用单元测试把行为锁死，上线之后只要环境不变，输出就不会变。但基于大语言模型的Agent完全打破了这条假设。同样的用户问题，Prompt里多一个词、少一个词，上下文里多一轮历史对话，模型输出的质量就可能天差地别。

这带来一个很尴尬的事实：你无法在发布前穷尽所有错误。哪怕你的测试集做得再仔细，覆盖了几百个case，真实用户还是会用你完全没想到的方式提问。系统错误率不是零，这不是bug，而是基于概率模型的天然属性。

既然错误不可避免，那唯一合理的策略就是：让系统能从错误中学习。每一次用户纠正、每一次回答被点踩、每一次用户手动给出正确答案，本质上都是免费的标注数据。问题是，大部分团队根本没有建立采集这些信号的管道，更别提把这些信号变成模型和Prompt的改进动力。

1.2 静态部署的最大浪费：用户的反馈没有被回收

我见过不少团队的迭代方式是这样的：运营或客服同学发现Agent答错了，截图发到群里，算法同学看到之后手工改一条Prompt，或者加一条few-shot示例，然后发版。听起来没问题对吧？但实际运行起来你会发现三个问题。

第一，这种人工驱动的迭代完全依赖“有人恰好发现了问题”。用户点踩之后如果没有人工去翻后台，这个错误就永远沉在日志里。第二，即便有人发现了，修完一个case往往又破坏另一个case，因为没有回归测试集来保护已有行为。第三，所有的修改都是“打补丁式”的，今天修A问题、明天修B问题，但那些高频、系统性的错误模式从来没有人做过数据层面的统计分析。

真正让我下决心改造的是一次线上事故：用户连续问了三次同一个问题，Agent三次都推荐了同一个错误方案，用户最后在对话框里打出“你是傻子吗”。日志里能看到他输入了正确的操作路径，但我们没有任何机制把这条路径学习进来。那一刻我意识到，这不是某一个Prompt的问题，是整个系统架构缺失了“从用户反馈中学习”的环节。

1.3 进化闭环的基本框架：四层结构

我最终落地的方案，整体框架可以用四个层级来理解：

• 反馈采集层：从用户交互中采集显性和隐性反馈信号，形成结构化的训练数据。
• 分析与挖掘层：对反馈数据进行聚类、归因，找出系统性的错误模式和优化方向。
• 优化与训练层：基于分析结果执行两条优化路径——轻量级Prompt调整，和重量级模型微调。
• 验证与发布层：用回归测试集、在线A/B实验验证优化效果，灰度发布并持续监控。

这个框架听起来不复杂，但每一层落到工程实现上都有大量细节。下面我按实际实施顺序，把每一层的具体做法和判断标准展开讲。

2. 反馈信号从哪里来：把用户的“不满”变成结构化数据

2.1 显性反馈与隐性反馈的区别及采集策略

反馈信号分两类。显性反馈是用户主动表达的态度，最典型的就是点赞/点踩按钮，或者“这个回答有帮助吗”的评价入口。显性反馈最干净、最直接，但问题在于参与率低——大多数用户不会主动点踩，他们只会默默离开或者换一种方式重问。

所以隐性反馈才是真正的金矿。我在系统里埋了这么几个隐性信号：

• 回复后用户是否立即重新提问：如果用户收到答案后立刻换了措辞再问一遍，说明答案大概率没解决问题。
• 用户是否手动复制/粘贴了其他信息：很多用户会从别处复制正确信息粘贴到对话框，这其实是隐式的“正确答案”。
• 多轮对话中用户是否出现“纠正性语句”：比如“不是这个”“我说的是X”“你理解错了”这类表达。
• 会话是否提前中断且任务未完成：跟业务系统打通后，如果Agent声称“已完成”但后台订单状态没有任何变化，这就是强信号。
• 相似问题的复发率：同一个问题模式在时间轴上反复出现，说明之前的修复没有根治。

采集层我建议做成一个独立的埋点服务，不要在Agent主进程里直接写日志。我最初就是直接在业务里打印日志，后来清洗数据的时候痛不欲生。正确做法是把每一次Agent响应连同上下文快照一起发到消息队列，由独立的消费服务做结构化存储。这样一个好处是：未来加新的反馈信号不需要改Agent主代码，只需要在采集层加规则。

2.2 反馈事件的Schema设计

下面是我们实际在用的反馈事件结构，做了脱敏处理：

{ "event_id": "evt_20250107_001234", "session_id": "sess_8f3a2b", "user_id": "u_9e3d21", "timestamp": 1736265600, "feedback_type": "thumbs_down", "turn_id": 12, "user_message": "我要查上个月的账单明细，不是这个月的", "agent_response": "好的，以下是您本月（1月）的账单明细……", "modified_response": null, "intent_predicted": "bill_query_current_month", "intent_expected": "bill_query_last_month", "context_snapshot": [ {"role": "user", "content": "帮我看看账单"}, {"role": "assistant", "content": "请问您想看哪个时间段？"}, {"role": "user", "content": "我要查上个月的账单明细，不是这个月的"} ], "metadata": { "model": "base-agent-v1", "prompt_version": "20250101", "latency_ms": 1240 } }

你可能会问：context_snapshot会不会太大了？确实会，如果每轮都全量存储，存储成本不小。我的建议是只存与反馈事件相关的那个会话窗口，一般是返回事件前8轮到后2轮的上下文，超出这个范围的信息对训练和归因帮助有限。另外metadata里一定要带上prompt_version和model版本——没有这两个字段，你后面做归因的时候根本不知道当前行为是哪一版配置产生的。

2.3 脏数据清洗和隐私合规

采集只是第一步，真正花时间的是清洗。第一次清洗时我发现，用户的“显性反馈”非常不可靠：有人手滑点踩，有人连续点踩好几次同一轮回复（可能是网络重复提交），还有人故意捣乱在评论里灌水。所以清洗规则必须包含：

• 去重：同一session同一轮的重复反馈只保留第一条。
• 矛盾处理：同一轮既有点赞又有点踩的，以最后一次动作为准。
• 内容过滤：反馈文本长度超过200字或包含明显无序字符的剔除；涉及个人隐私信息（身份证号、手机号等）的必须做脱敏或直接丢弃。
• 信号交叉验证：只有显性点踩或者“隐性信号命中两项以上”的case，才进入候选数据集。

隐私这块儿没有捷径，K-匿名化、字段级脱敏、访问控制是底线。我当时的做法是在采集层直接做字段过滤，有些敏感字段根本不允许进入消息队列，从源头避免数据合规风险。因为这块出了事不是技术问题，是合规事故，团队担不起。

3. 微调与Prompt优化：两条腿怎么分工，别一上来就动权重

3.1 一张决策表：什么时候改Prompt，什么时候做微调

很多团队拿到反馈数据后第一反应是“我们去微调一下模型”，这是最大的认知误区。微调不是万能药，成本高、周期长、容易翻车。更合理的做法是先根据问题的性质决定走哪条路径。我自己总结了一张决策表，非常直觉：

这需要说明，在实际操作中，有些问题你一开始判断不准到底该走哪条路。我的经验是：能靠Prompt解决的绝对不微调，Promp解决不了再考虑微调。因为微调的风险比Prompt大得多，最典型的是灾难性遗忘——你喂了新数据，模型可能把旧能力给忘了。

3.2 两条路径的成本对比

用大白话算一笔账。改Prompt的启动成本趋近于零——你只需要在现有Prompt文件里加几行指令，然后用回归测试集跑一遍，半小时内就能出结果。

而微调的成本是什么？以我当时用的基座模型为例，一次微调任务要经历：构造训练集（1~2天）、数据质量审核（半天）、训练任务跑起来（4~8小时甚至更久）、然后评估（半天以上）。加起来少说三到五个工作日。这还没算算力成本和对线上服务的资源挤占。

所以我的原则是：微调不是日常操作，是“阶段性手术”；Prompt优化才是日常迭代的主力手段。进化机制的健康状态应该是——大部分迭代靠Prompt，每几周或者出现系统性问题时做一次微调。

3.3 典型翻车案例：微调把旧能力给“修没了”

说一个真实踩过的坑。当时用户反馈Agent对“退订”意图的理解不准，我们收集了一批数据直接做了全参微调。拿去评估，退订意图的准确率从60%提到了85%，非常满意。结果上线第二天客服同学就来找我：怎么用户问收货地址，Agent开始答非所问了？

查下来才知道，微调数据里退订占比太高，模型把“地址相关查询”的模式也往退订方向带偏了。更麻烦的是，这个问题在离线评估里根本没发现，因为我们当时的回归集没有覆盖“地址查询”这类高频但旧的意图。后来我们的微调流程里加了硬性规矩——回归评估集必须覆盖所有核心意图，且微调后旧意图的指标下降超过5%就不允许上线。

这个案例想说明的是：微调是把双刃剑，它的收益和风险是并存的。如果你还没有一个像样的回归集，不要轻易微调，你根本不知道它把什么东西弄坏了。

4. 基于用户反馈的Prompt优化：从“拍脑袋改写”到“回归驱动迭代”

4.1 建立回归评估集：Prompt优化的地基

Prompt优化的核心动作不是“改文字”，而是“改完文字之后如何证明它变好了”。没有评估集，你所有的修改都只是在赌运气。

我花了整整一周时间从历史反馈里构建了一个回归集，规则如下：

• 数量：300条case。太少没统计意义，太多标注成本扛不住。
• 构成：200条历史真实错误case（从反馈日志里抽样），50条边界case（措辞极端、意图模糊、多轮转折），50条“绝不能坏”的黄金case（核心业务场景的标准问答）。
• 标注方式：每条case标注期望答案的关键要点，不需要完整回答，只需要列出“必须包含哪些信息点”，这样评估时可以用LLM辅助做要点匹配，不用纯人工逐条看。
• 版本管理：整个回归集放Git里，每次变更走PR评审。

这个回归集的价值会在后面的每一次迭代中体现。比如你想在Prompt里加一句“如果用户说‘上个月’指的是当前日期对应的上一个自然月”，看似合理，但如果回归集里有几条case是用户说“上个月”其实指的是“本月”的口语场景，你就能立刻发现冲突。

4.2 Prompt迭代的标准流水线

我的prompt迭代流程非常固定，每个周期大概两三小时就能完成：

1. 采集错误Case并聚类：从反馈池里捞最近一周的错误case，用LLM做语义聚类，看top主题。比如“时间范围理解错误占30%”“余额查询和账单查询混淆占20%”这样。
2. 选择最高频问题：一次只处理一个主题。同时改多个主题会让回归集失效，因为分不清是哪个改动导致了指标变化。
3. 设计Prompt补丁：针对该主题，明确写出正确的行为规则和反例说明。我给Agent的Instruction里加的任何一句话都要做到“可判定”——就是能明确知道Agent做对了还是做错了，而不是模糊的“请更好理解用户意图”。
4. 跑回归对比：用修改前后的两个Prompt分别跑回归集，对比指标。重点关注两点：目标case的通过率是否提升，黄金case的通过率是否下降。
5. 记录日志：每一次改动都在CHANGELOG里记录：改了什么、为什么改、回归通过率变化多少。我后来查过很多次，如果没记录，两周之后你根本想不起某个限制条件是为应对什么case加进去的。

4.3 Prompt补丁的具体写法示例

拿我们踩过最多坑的一个场景举例：用户已经明确表达了“不要推荐了”，Agent还在继续推荐备选项，引发大量点踩。数据分析发现，这个错误模式占所有点踩事件的25%。

我加的一段Prompt是这样的：

当用户明确表示“不需要推荐”、“不要再给我选项”、“我已经决定了”等否定意图时， 禁止继续提供任何新的备选项或建议。 此时只做两件事： 1. 确认用户的最终选择； 2. 如果用户没有给出明确指令，询问是否需要进入下一步操作。 判断规则：如果回答里出现了新的推荐选项名称，则该回答判定为违规。

加这段的启示是：好的Prompt补丁要向模型提供三重信息——触发条件（什么场景生效）、期望行为（具体做什么）、违规判定（怎么样算做错了）。第三个尤其重要，因为很多LLM错误在于它“不知道自己做错了”，给它一个明确的判定标准会让行为改变得更彻底。

4.4 为什么回归驱动比“手工精调”更可靠

很多老派的Prompt工程师喜欢靠手感改Prompt：觉得这个Prompt“应该”更有逻辑，就换一种措辞。我不否认经验的作用，但Prompt优化本质上是一个搜索过程——你是在尽量大的解空间里寻找更优的文本配置，没有回归集你根本不知道自己找没找到。

有回归集和没有回归集的差距，在我实测里非常巨大。对比同一个人优化的同一个问题：没有回归集时，修改了5版Prompt，目标case通过率提升忽高忽低，黄金case还莫名其妙掉点；有了回归集之后，平均每2.5版就能找到一版双指标都正向的配置。这不是玄学，是因为回归集把“这次改动到底做对了没有”这个问题从主观判断变成了可观察的事实。

5. 模型微调闭环：数据配比、训练配置与防遗忘

5.1 训练数据构造：不是把反馈日志直接喂给模型

很多文章聊微调都止步于“收集数据然后微调”，实际上最花时间的工作量在数据构造上。直接把反馈日志喂给模型是不可行的，原因很多：日志里有上下文痕迹、有多轮对话脏数据、有信息冗余，模型学到的不是你想要的“应该怎么回答”，而是各种乱七八糟的交互噪声。

我的数据构造流程分五步：

1. 候选筛选：从反馈池里捞最近几周有明显修正信号的case。
2. 意图标注：对每个case标注正确的意图和行为。这步我一开始用人工，后来改成“LLM预处理+人工抽检”的混合模式。
3. 重写生成：把原对话改写成标准的指令数据对。也就是干净的user prompt + 期望的assistant response。注意，assistant response必须是我们希望Agent“重新生成”的样子，而不是用户自己纠正的内容原文。用户手工输入的内容往往口语化、碎片化，直接学会让模型学会说“用户话”，那更灾难。
4. 质量审核：按一定比例（我当时是20%）人工审核，发现低质量数据立即打回并修正生成规则。
5. 格式统一：确认所有样本符合训练框架的格式要求，比如是否有system提示、是否需要包上工具的调用格式等。

5.2 数据配比：对抗灾难性遗忘的关键

数据配比是整个微调环节最容易被忽略的部分。很多人犯的错误是：反馈里“退货流程”的错误case占了60%，于是训练集里退货流程也占60%，结果微调出来的模型满脑子都是退货流程，其他意图全废。

我在实践里的具体做法：

• 目标问题数据：约占40%~50%，这是本次微调要解决的核心问题。
• 同类但非目标数据：约20%，防止模型对目标问题过拟合而丢失同领域的泛化能力。
• 历史核心数据：约30%~40%，从之前微调或初始优质数据中抽取的核心样本，目的是维持旧能力。
• 通用对话数据：少量，约5%~10%，保持模型基本对话能力。

这个比例在不同场景下要动态调整。如果这次微调的目标问题占比很高、系统性问题很严重，可以适当把目标数据提到60%，但核心数据不能低于25%。再低就非常容易出现忘掉旧能力的现象。

5.3 LoRA还是全参微调？训练参数的经验值

关于训练方式，我前后做过对比。全参微调在业务数据量不大的场景下收益并不比LoRA高多少，但成本和风险都高出好几个量级。所以我现在的主力方案是LoRA，一般配置如下（供参考，不一定适合所有场景）：

• rank：16~32。太低学不动复杂格式，太高容易过拟合。
• 学习率：1e-4到3e-4之间，比全参微调高一个量级。
• epoch数：2~4个epoch。超过4个我基本都观察到了过拟合现象——训练集指标继续升，回归集指标开始掉。
• 最大序列长度：按Agent实际上下文长度设置，截断策略要跟线上保持一致。
• 权重衰减：0.01。

这些参数不是拍脑袋，而是我做了多次实验后的经验区间。特别指出，epoch数最值得关注，建议每完成一个epoch就在回归集上评估一次，而不是等训练全部结束再看。一旦发现回归集指标开始下降，立刻停止训练。这个时候的模型参数往往比训练满epoch的效果更好。

5.4 微调后的评估：离线过了不代表能上线

微调评估我有两层。第一层是离线回归——用前面构建的回归集，跑改前和改后的对比。需要看的指标：目标问题通过率提升多少、黄金case是否下跌、以及各意图的分项指标是否稳定。

第二层是轻量的影子测试——把微调后的模型和线上模型在最近一周的真实流量上同时跑（不含实时决策），比较两者的输出质量。这一步能提前发现一些离线集覆盖不到的问题，比如输出长度暴增、拒绝回答问题频率上升、语气偏移等。

我经历中最有价值的一次评估，是发现微调后模型对“不知道”的表达频率明显下降——听起来像是好事？但在影子测试里发现，模型开始“不懂装懂”，对模糊问题给出貌似合理的错误答案。从用户点踩率来看，这种错误比“诚实地说不知道”伤害大得多。这个发现如果在离线阶段就看总量指标，很可能会被淹没在整体“变好”的假象里。所以评估一定要拆维度，至少要拆到意图级别和错误类型级别。

6. 进化机制的整体编排：从反馈到发版的完整链路

6.1 整个闭环的数据流和角色分工

讲完单独的模块，说说整个闭环怎么串起来。按时间顺序，一个完整的进化周期大概是这样的：

1. 线上Agent产生用户交互，埋点数据源源不断进入消息队列。
2. 每小时跑一次ETL任务，把原始交互数据整理成结构化的反馈事件明细表。
3. 每天跑一次统计分析，生成当天的“错误热点”报告——哪些意图、哪些错误类型在上升。
4. 分析师或我本人（人）每周看一次热点报告，决定本周迭代目标。这一步必须有人的判断，不能全自动。
5. 根据目标决定走Prompt优化还是模型微调路径（见第3章的决策逻辑）。
6. 在回归集上验证改动，通过后进入灰度发布。
7. 灰度期间持续监控核心指标，如果没有异常，逐步扩大到全量。
8. 两周到一个月后，积累了足够新的反馈数据，进入下一个循环。

我特别想强调第4步“人的判断”。很多人追求全自动的进化体系，我不太认同——模型自己评估自己的输出，这里面有天然的盲区。更稳妥的形态是人机协同：机器负责采集、聚类、初筛、回归检测，人负责定方向、做最终判断。就像推荐系统不会完全让模型决定给用户推什么一样，它背后还需要策略和人工位。

6.2 灰度发布与回滚策略

任何Prompt改动和模型更新，我都建议走灰度，不要一把梭。有一套简单的灰度策略分享：

• 阶段一（1%）：放出1%的流量，观察核心指标是否出现立即性异常，比如报错率、超时率。
• 阶段二（10%）：放大到10%，观察用户反馈相关的指标变化——点踩率、重问率、任务完成率。在这里观察至少24小时。
• 阶段三（50%）：如果一切正常，放大到50%再观察一天。
• 阶段四（全量）：全量发布。同时保留24小时内一键回滚的能力。

回滚预案一定要提前写好。对Prompt来说，回滚就是切回旧版本配置；对微调模型来说，回滚就是把模型服务切回上一个版本。我们在实践中把这两个都做成了独立的发布通道，避免“为了回滚Prompt结果把模型也一起回滚了”这种尴尬情况。

6.3 进化频率的把握

进化不是越快越好。我观察到的合适节奏是：Prompt层的优化每周可以来1~2次，微调层每2~4周做一次就足够了。太频繁的微调有几个问题：一是训练数据和线上数据的分布差距不够大，微调增量有限；二是每次微调都要冻结当前模型的状态做评估，频繁冻结会影响正常迭代节奏；三是如果你的Agent行为变化太快，下游依赖方（比如运营后台、用户习惯）会感到困惑——用户还没适应新版的行为方式，你又改了。

从另一个角度看，没有显著数据变化的更新宁可不做。每一次更新都伴随风险，所以只有当分析结果明确指向某个具体问题且该问题的影响面足够大时，才值得动一次。

7. 落地过程中的几个关键经验与反思

走到这里，整个“基于用户反馈的模型微调+Prompt优化流程”的主干已经完整了。最后分享几个我在落地这个机制时总结的体会，可能比上面的流程干货更值钱。

第一，先有反馈采集，再谈优化。很多团队在一开始就急着微调模型，其实连反馈数据都没有。如果你想开始做自我进化，第一周只做一件事：把反馈埋点做好，把数据管道搭通，把数据可视化做出来。数据没流通之前，谈任何优化都是空中楼阁。

第二，Prompt优化的ROI远高于模型微调，先从Prompt开始。在我实际项目中，第一个进化周期完全靠Prompt优化就把核心问题case的通过率从65%拉到了82%，零微调成本。直到第二个月，数据积累到需要模型学习新的表达分布时，才开始第一次微调。把微调往后推不是拖延，是在等数据成熟。

第三，没有回归集之前，禁止任何修改。这条我当成团队铁律。没有回归集的Prompt修改就是赌博，你可能“感觉”改好了，但你无法证明它没改坏别的东西。尤其是Agent这种复杂度高的系统，“按下葫芦浮起瓢”是常态，回归集是你唯一能按住葫芦的东西。

第四，每次只改一件事。我踩过最深的坑，就是在一轮迭代里同时改了Prompt结构、加了几个新示例、还换了模型参数。结果指标下来了，但完全定位不到是哪个改动起了作用。从那以后，我所有优化都坚持单变量原则——一次迭代只改动一个维度，其他全部冻结。虽然看起来慢，但积累的可信知识是完全不同的量级。

最后，这个机制本身也需要“进化”。它不是一个一次搭好就能躺着用的流水线，而是一个需要持续调优的系统——反馈信号的定义需要根据业务变化调整，回归集需要不断补充新的错误模式，数据配比需要跟着模型版本和目标变化而改变。把这些当作一个长期运营的工程系统来对待，而不是一个一次性交付的项目，它才能真正发挥出“自我进化”的价值。