目录:

2026 年，一个事实已经无法忽视：模型训练不再是一项研究活动，而是一项系统工程。

预训练需要万卡集群和 PB 级数据管线，强化学习需要奖励模型和 RLHF/DPO 的工程化流水线，推理优化涉及量化、蒸馏、speculative decoding 等一整套工具链，Agent 能力构建则横跨 function calling、长上下文、规划与工具使用的多维调优。任何一个方向的突破，如果不能在其他环节配合落地，就只是一篇论文，不是一个产品。

这意味着什么？模型本身正在变成标准化基础设施。 就像今天没有哪家 SaaS 公司拿”我们用了 PostgreSQL”当竞争优势一样，未来也不会有哪家 Agent 公司仅靠”我们微调了一个更好的模型”赢得市场。

那么 To B Agent 创业的制胜变量到底是什么？

一个被忽视的事实：Agent 的竞争不在模型层

先看今天 To B Agent 赛道的典型创业故事：

1
2
3
团队 A：3 个 AI 研究员，从大厂出来，花 6 个月微调了一个行业模型
团队 B：5 个工程师 + 2 个行业专家，花 3 个月搭了一套 Agent 工作流
团队 C：3 个产品经理 + 3 个工程师，花 2 个月做了个能用的 MVP，然后每天泡在客户现场

半年后，团队 C 的客户续约率最高。

为什么？因为 To B Agent 要解决的问题不是”模型能不能理解这段话”，而是**“这个 Agent 能不能像一个靠谱的初级员工一样，把一件具体的事做好”**。

一个能替代初级岗位的 Agent，面对的是真实业务场景中无穷无尽的边界条件：

  • 客户的审批流程有 17 种例外情况
  • 报价单的格式每个行业甚至每家客户都不一样
  • “帮我整理一下这个表”在不同上下文里意味着完全不同的操作
  • 同一个任务，张三要的是简洁版，李四要的是详细版

这些问题，模型层面的能力提升帮不了你。只有用户反馈才能告诉你：你的 Agent 在真实场景里到底做得怎么样。

用户反馈是 To B Agent 的核心资产

让我把这个论点说得更直白一些：

在 To B Agent 赛道，你的模型、你的架构、你的 Prompt 工程——这些都是”赌注”。只有用户反馈闭环，才是你的”底牌”。

为什么？看一个对比：

能力

可复制性

竞争壁垒

基础模型能力

高——开源模型快速追赶

低

Prompt/工作流工程

中——聪明的团队几周就能复刻

低

行业知识库

中——可以购买或爬取

中

真实场景的用户反馈数据

低——只有你的客户在你的产品里产生

高

基于反馈的持续优化能力

极低——需要数据 + 工程 + 产品的系统性投入

极高

最后两行是关键。你的竞争对手可以用同样的基础模型、抄你的 Prompt、买同样的行业数据——但他拿不到你的客户在你的产品里产生的那些真实反馈信号。

这些反馈数据是你独有的场景资产。而且它有飞轮效应：反馈越多 → Agent 越好 → 用户越愿意用 → 反馈更多。

“多快好省”：定义你的 Agent 执行指标

在构建反馈闭环之前，先回答一个问题：你优化的目标是什么？

对一个替代初级岗位的 To B Agent 来说，用户关心的核心指标可以归纳为”多快好省”四个维度：

维度

含义

度量方式

示例

多（覆盖度）

能处理多少种任务/场景

任务完成率、场景覆盖率

能处理 80% 的常见审批类型

快（效率）

完成任务要多长时间

端到端耗时、人工介入次数

一份报告从 30 分钟降到 5 分钟

好（质量）

输出质量是否达标

准确率、返工率、用户满意度

生成的合同初稿一次通过率 90%

省（成本）

消耗了多少资源

Token 消耗、API 调用次数、人工复核成本

单任务成本 < ¥0.5

这四个维度之间存在张力——追求”好”可能牺牲”快”和”省”，追求”多”可能降低”好”。你的产品策略决定了四个维度的优先级排序，而用户反馈告诉你当前在每个维度上的真实表现。

为每种任务类型设定基线

不要试图用一组指标衡量所有任务。不同任务类型的”多快好省”权重完全不同：

1
2
3
4
5
6
7
8
9
10
11
任务类型：合同审查
  多: 权重 0.2 — 场景相对固定
  快: 权重 0.2 — 不急，但不能超过 1 小时
  好: 权重 0.5 — 错一个条款后果严重
  省: 权重 0.1 — 对比律师费用，成本不敏感

任务类型：客服工单分类
  多: 权重 0.3 — 要能覆盖各种奇怪的问题
  快: 权重 0.3 — 实时响应，秒级
  好: 权重 0.2 — 分类错了可以人工纠正
  省: 权重 0.2 — 量大，成本敏感

这种按任务类型的指标拆分，是后续一切优化的基础。

构建反馈闭环：从信号采集到 Agent 进化

反馈闭环不是”加一个点赞按钮”。它是一套完整的系统，包含四个环节：

1
2
3
采集 → 归因 → 实验 → 部署
 ↑                      │
 └──────────────────────┘

第一环：采集——让反馈信号无处不在

最大的误区是只依赖显式反馈（用户主动打分、点赞/踩）。显式反馈的覆盖率通常低于 5%——绝大多数用户用完就走了，不会停下来给你评分。

你需要建立一套隐式反馈 + 显式反馈的复合信号体系：

隐式信号（自动采集，零用户成本）：

用户行为

信号解读

权重

Agent 输出后，用户直接采纳

满意

+1.0

用户对输出做了小幅编辑（<20%）

基本满意，有微调

+0.5

用户对输出做了大幅编辑（>50%）

不满意，但愿意修正

-0.5

用户放弃 Agent 输出，自己重做

完全不满意

-1.0

用户追问细节或要求补充

覆盖不足

-0.3

用户要求重做（“重新来”）

输出质量差

-0.8

用户把 Agent 输出转发给同事

高质量输出

+1.5

用户用同样的指令再次调用（第二天/下周）

形成使用习惯

+2.0

显式信号（需要用户参与，但信息量大）：

  • 👍/👎 按钮——简单但信息量低
  • 选择题反馈—���“这个输出哪里不好？①不准确 ②太啰嗦 ③格式不对 ④缺少信息”
  • 自由文本反馈——信息量最大，但分析成本高

产品设计的关键原则：让隐式信号覆盖 95% 的反馈采集，显式信号只在关键节点触发。 比如：

  • 当检测到用户对 Agent 输出做了大幅编辑时，弹一个轻量级反馈框：“我注意到你做了较多修改，是哪里不够好？”
  • 当 Agent 连续 3 次被追问时，记录为”需要人工审查的 case”
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
class FeedbackCollector:
    def on_task_complete(self, task_id, agent_output, user_actions):
        signals = []

        # 隐式信号自动采集
        if user_actions.accepted_directly:
            signals.append(("implicit_accept", 1.0))
        elif user_actions.edit_ratio < 0.2:
            signals.append(("minor_edit", 0.5))
        elif user_actions.edit_ratio > 0.5:
            signals.append(("major_edit", -0.5))
            # 触发显式反馈采集
            self.request_explicit_feedback(task_id, "large_edit")
        if user_actions.forwarded_to_others:
            signals.append(("forwarded", 1.5))

        self.store(task_id, signals)
    # generated by hugo's coding agent

第二环：归因——从信号到诊断

有了反馈信号只是第一步。更重要的是搞清楚为什么好、为什么差。

归因需要在三个层次上进行：

层次 1：任务类型归因

1
2
3
4
5
上周 Agent 执行了 500 个任务：
├── 合同审查（120 次）: 满意率 85% ✅
├── 报价单生成（200 次）: 满意率 62% ⚠️ ← 重点关注
├── 会议纪要整理（100 次）: 满意率 91% ✅
└── 数据报表制作（80 次）: 满意率 45% ❌ ← 紧急处理

层次 2：失败模式归因

1
2
3
4
5
报价单生成满意率 62%，76 次不满意：
├── 格式错误（30 次，39%）: 客户 A 要横版，Agent 输出竖版
├── 价格计算错误（22 次，29%）: 阶梯定价逻辑出错
├── 缺少必要信息（15 次，20%）: 未带入客户的历史折扣
└── 其他（9 次，12%）: 包含过时的产品型号

层次 3：根因归因

1
2
3
4
价格计算错误（22 次）根因分析：
├── 12 次：阶梯定价规则没有写进 Prompt → Prompt 优化
├── 7 次：客户的定价规则更新了，Agent 用的是旧版 → 知识库更新机制
└── 3 次：模型推理错误（数学计算） → 需要增加计算校验步骤

三层归因做下来，你得到的不是一个模糊的”用户不满意”，而是明确的优化动作清单。每个问题都有具体的解法。

第三环：实验——用场景数据驱动优化

有了诊断，接下来是实验。这是很多团队做得最差的环节——他们要么凭直觉改 Prompt，要么一次性做大量修改，根本分不清哪个改动起了作用。

核心原则：一次只改一个变量，用真实场景数据验证。

建立你的 Eval 数据集

这是场景数据的最高价值用法——从真实执行记录中提取评测数据集：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
class ScenarioEvalBuilder:
    def build_eval_set(self, task_type, min_cases=50):
        """从真实执行记录中构建评测数据集"""
        cases = []
        for record in self.get_recent_records(task_type):
            cases.append({
                "input": record.user_instruction,
                "context": record.business_context,
                "agent_output": record.output,
                "user_feedback": record.feedback_score,
                "user_edits": record.edited_version,  # 用户修正后的版本 = 黄金标准
                "failure_mode": record.diagnosed_failure,
            })

        # 优先选择有明确正/负信号的 case
        positive = [c for c in cases if c["user_feedback"] > 0.5]
        negative = [c for c in cases if c["user_feedback"] < -0.3]

        return {
            "golden_set": positive[:25] + negative[:25],
            "size": len(cases),
            "positive_ratio": len(positive) / len(cases),
        }
    # generated by hugo's coding agent

这里有一个容易被忽视的宝藏：用户修改后的版本就是你的黄金标准答案。 用户在 Agent 输出基础上做的每一次编辑，都是一条免费的标注数据。

实验流程

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
识别要优化的任务类型（如：报价单生成）
    │
    ▼
分析失败模式，选择最高频的问题（如：格式错误）
    │
    ▼
提出优化假设（如：在 Prompt 中增加客户特定的格式模板）
    │
    ▼
在 Eval 数据集上运行 A/B 测试
    │
    ├── 原始 Prompt：格式正确率 61%
    └── 修改后 Prompt：格式正确率 89%
    │
    ▼
检查是否引入副作用
    │
    ├── 价格准确率：94% → 93%（可接受）
    └── 信息完整度：88% → 87%（可接受）
    │
    ▼
主指标显著提升 + 无严重副作用 → 上线
    │
    ▼
在真实流量中持续监控 48 小时
    │
    ├── 确认改善 → 永久保留，更新 Eval 基线
    └── 未达预期 → 回滚，分析原因

分层实验策略

不是所有优化都需要同样的实验力度。按影响范围分层：

层级

改动类型

实验要求

示例

L1 轻量

Prompt 措辞微调

跑 10 条 Eval case

把”生成报价单”改为”按模板生成报价单”

L2 中等

工作流步骤调整

跑 50 条 + 48h 灰度

增加一步格式校验

L3 重大

架构级变更

跑全量 Eval + 1 周灰度

从单步生成改为”生成-校验-修正”三步流程

第四环：部署——灰度与回滚

To B 场景对稳定性的要求远高于 To C。一个 Agent 突然行为变了，客户的信任就没了。

灰度发布策略：

1
2
3
4
5
6
7
8
9
10
11
12
13
修改通过 Eval 验证
    │
    ▼
Phase 1: 内部测试（团队自己用 2 天）
    │
    ▼
Phase 2: 种子客户灰度（选 2-3 个关系好的客户，开放 1 周）
    │    收集反馈，确认无回归
    ▼
Phase 3: 全量发布（监控指标 48 小时）
    │
    ├── 指标正常 → 完成
    └── 指标异常 → 一键回滚到上一版本

关键：保留每个版本的完整快照（Prompt + 工作流 + 知识库版本），确保可以随时精确回滚。

场景数据的飞轮：越用越好的正循环

当上述四个环节跑通之后，你会发现一件美妙的事情——系统开始自我加速。

1
2
3
4
Week 1:  100 个任务记录 → 粗粒度优化 → 满意率 60%
Week 4:  2000 个任务记录 → 精细化归因 → 满意率 72%
Week 12: 10000 个任务记录 → 按客户/场景精准优化 → 满意率 85%
Week 24: 50000 个任务记录 → Agent 比新来的实习生靠谱 → 满意率 92%

飞轮的关键在于场景数据的网络效应：

  1. 客户 A 踩的坑，客户 B 不用再踩。 客户 A 发现报价单的阶梯定价逻辑有问题，修复后这个改进惠及所有客户。

  2. 用户修正即标注。 每一次人工编辑都在告诉你正确答案应该是什么，这些数据积累起来，就是任何竞争对手都买不到的行业训练数据。

  3. 失败模式库越来越全。 第一个月你只知道 10 种报价单出错方式，半年后你知道 200 种——每一种都有对应的解法。

  4. Eval 数据集越来越硬。 基于真实场景的 Eval 集，远比人工构造的测试集更能反映真实需求。你的 Eval 集越强，新的优化就越可靠。

1
2
3
4
5
6
7
8
9
10
11
12
                      场景数据飞轮

     ┌─────────────────────────────────┐
     │                                 │
     ▼                                 │
用户使用 Agent ──→ 产生执行记录 ──→ 采集反馈信号
                                       │
                                       ▼
Agent 能力提升 ←── 部署优化 ←── 实验验证 ←── 归因分析
     │
     ▼
用户更愿意用 ──→ 更多执行记录 ──→ 更多反馈信号 ──→ ...

这就是 To B Agent 的真正护城河。 你的竞争对手可以抄你的架构、挖你的人、用同样的模型——但他拿不到你的场景数据飞轮。这个飞轮转了 6 个月之后，你的 Agent 对这个行业的理解深度，不是新入场者能够追赶的。

给创业团队的实操建议

Day 1-30：先跑通最小闭环

不要花 3 个月搭一个完美的反馈系统。先做最简单的版本：

  1. 记录每一次 Agent 执行的输入和输出——存到数据库里就行
  2. 在输出旁边放一个 👍/👎 按钮——能收到 3% 的反馈就够了
  3. 每天人工审查 10 条差评 case——用人脑做归因，用 Excel 记录
  4. 每周改一次 Prompt——基于那 10 条 case 的分析

这个最小闭环不需要任何 AI 辅助评估、不需要自动化实验平台、不需要灰度发布系统。它就是”人工看反馈、人工改 Prompt、看看下周是不是好了”。

但它会教你三件事：

  • 用户真正在意什么（而不是你以为他们在意什么）
  • 你的 Agent 在哪些场景下最脆弱
  • 什么样的反馈信号最有诊断价值

Day 30-90：自动化关键环节

当你对反馈模式有了直觉后，开始自动化：

  1. 隐式信号采集器——自动检测用户编辑行为、追问行为、放弃行为
  2. 自动归因管线——用 LLM 对差评 case 做分类和根因分析
  3. Eval 数据集自动构建——从真实执行记录中自动提取和更新评测集
  4. Eval 自动化运行——每次 Prompt 修改后自动跑 Eval 集

Day 90-180：建立系统性优化能力

这个阶段的目标是让优化变得可预期、可复制：

  1. 按任务类型建立独立的 Eval 集和指标体系
  2. 建立实验记录和版本管理——每轮实验的假设、修改、结果、决策都有据可查
  3. 灰度发布机制——重大修改先在种子客户上验证
  4. 客户级别的 Agent 配置——不同客户的 Agent 行为可以独立调优

团队配置建议

1
2
3
4
5
6
7
8
9
早期（< 10 人）:
  产品/运营 × 1 — 每天看反馈，定义优化优先级
  全栈工程师 × 2 — 搭建反馈采集和 Eval 管线
  AI 工程师 × 1 — Prompt 优化和工作流设计
  行业专家 × 1 — 提供领域知识，审查 Agent 输出质量

不要一开始就招 ML Research：
  ❌ 花 6 个月微调一个行业模型
  ✅ 花 6 个月把反馈闭环跑到飞轮效应

一个思想实验

假设今天有两家公司同时入场做”AI 财务审计助手”：

公司 A：花 6 个月和 500 万，微调了一个审计专用模型。能力确实比 GPT-4o 强 15%。

公司 B：用 GPT-4o + 好的 Prompt 工程，2 个月做出 MVP。剩下 4 个月和 500 万全部投入到客户现场，采集了 50000 条真实审计场景的反馈数据，迭代了 20 个版本的 Agent 工作流。

6 个月后，公司 B 的 Agent 在真实审计任务上的表现大概率超过公司 A——因为 B 的 Agent 见过的真实场景、踩过的真实坑、积累的真实解法，是 A 在实验室里无论如何也模拟不出来的。

更要命的是：12 个月后，当公司 A 终于开始接客户的时候，公司 B 的飞轮已经转了半年了。

写在最后

模型训练已经变成了系统工程。这意味着模型能力的差距在收窄，而不是拉大。当基础模型的能力越来越接近时，To B Agent 产品的竞争就会下沉到最后一公里——你的 Agent 到底能不能在客户的真实业务场景中，多快好省地把活干好。

能回答这个问题的，不是你的模型有多强，不是你的架构有多精妙，而是你有没有一个高效运转的用户反馈闭环。

模型是入场券，反馈是记分牌。 别在入场券上花太多时间了——进了场，盯紧记分牌。

AI  AI-agents  enterprise  startup  product  feedback-loop  agent-optimization 

原文链接: 别再卷模型了：To B Agent 创业，用户反馈才是生死线