模型厂商做 Agent：别急着卖 SDK，先做一个用户愿意天天打开的产品

很多模型厂商都卡在一个很尴尬的位置：模型很强，API 也很便宜，文档更是写了几十页。结果呢？

开发者注册、拿 Key、跑通 Demo，然后就没下文了。

SDK 是基础设施。基础设施当然重要，可它离真实用户太远。你看不到用户在什么任务上卡住，看不到哪一步让人想骂街，也很难知道用户为什么用了三天就走。

如果目标是做长期的 Agent 生意，更值得投入的方向，是 Agent Harness Product：一个能把模型、工具、上下文、工作流、反馈闭环全都装进去的可用产品。

说白了，别只卖发动机。得先造一辆人愿意每天开的车。🚗

Agent Harness Product 到底是什么？

可以把它理解成 Agent 的“操作台”。

模型负责思考和生成，Harness 负责把模型真正带进工作场景。用户不需要研究 Prompt、不需要配置一堆参数，也不用手动复制内容到十个网页里。

一个够用的 Harness，通常要管住这些事：

• 任务入口：用户怎么下达需求，是聊天、表单、文件拖拽，还是浏览器侧边栏？
• 上下文管理：Agent 能否读懂当前项目、历史对话、公司资料和用户偏好？
• 工具调用：能不能查网页、读文档、操作表格、发邮件、调用内部系统？
• 过程控制：用户能否看到 Agent 正在干什么，能否中途暂停、修改、重试？
• 结果交付：输出是一段废话，还是一份能直接发出去的邮件、表格、报告或代码 PR？
• 反馈闭环：用户点了哪里、改了哪里、在哪一步放弃了，产品团队能不能拿到？

SDK 解决的是“开发者如何调用模型”。

Agent Harness Product 解决的是“普通人如何把一件事办完”。

这两个方向并不冲突，但资源有限时，优先级差别很大。

为什么只做 SDK，很难拿到真正有价值的数据？

API 调用记录能告诉你：

• 调了多少次
• 输入输出有多长
• 哪个模型更常用
• 哪段时间流量高
• 接口有没有报错

这些数据有用，却很像看一家餐厅的水电账单。

你知道厨房很忙，却不知道顾客觉得哪道菜难吃。

真正决定 Agent 产品走向的数据，藏在用户行为里：

• 用户输入任务后，多久开始追问？
• Agent 调工具失败时，用户是重试、手动接管，还是直接关页面？
• 用户拿到结果后，复制了哪一段？删改了哪一段？
• 哪类任务完成率高，哪类任务总在第三步崩掉？
• 用户愿不愿意第二天回来继续用？

SDK 模式下，这些行为大多被客户应用截走了。模型厂商只看到请求进来、请求出去，中间发生了什么，基本是黑箱。

而 Harness 产品天然站在任务现场。

比如一个“帮我整理客户会议纪要”的 Agent。用户上传录音、确认参会人、删掉敏感段落、补充待办人、导出飞书文档。这一连串动作，都是极其宝贵的产品信号。

它能告诉你：

用户真正要的，可能不是“总结能力更强”，而是“自动识别负责人，并同步到待办系统”。

这种洞察，靠模型排行榜和 API Token 消耗量，根本挖不出来。

用户量不是靠“模型很强”堆出来的

不少团队一做 Agent，就把重心放在工具数量上。

接了 100 个插件，首页摆得像五金店货架。看着很厉害，用户打开后却不知道该点哪个。

这很常见，也很致命。

用户要的不是一个“什么都能做”的机器人。用户要的是下午 5 点半时，能帮自己把明天会议材料收拾好的助手。

想拿到用户量，产品体验要排在插件可定制化前面。

先把一个高频任务打穿

别一上来做“万能办公 Agent”。这个词听起来威风，落地时通常会变成万能翻车现场。

挑一个任务，要求很简单：

• 发生频率高
• 用户痛感强
• 完成结果容易判断
• 有明确的交付物

适合起步的场景包括：

| 场景 | 用户的真实需求 | 好结果长什么样 | | --- | --- | --- | | 会议纪要 | 录音太长，整理太烦 | 纪要、待办、负责人、截止日期齐全 | | 行业调研 | 网页太多，信息太散 | 来源可追溯的结论和对比表 | | 销售跟进 | 会后忘记发邮件 | 一封符合客户上下文的跟进邮件 | | 代码排错 | 报错信息看不懂 | 定位原因、修改建议、可运行补丁 | | 周报整理 | 一周工作碎成一地 | 按项目归类、可直接提交的周报 |

做完后问一个朴素的问题：

用户会不会把结果直接拿去用？

如果还要复制、粘贴、改半天，那只是一个展示模型能力的 Demo，不是产品。

Agent 体验，重点盯住这 5 个环节

1. 让用户知道该怎么开口

空白聊天框很自由，也很容易让人发呆。

用户面对一个新 Agent，脑子里常常只有一句：“所以我该说啥？”

把常见任务做成入口卡片，直接给可点击的示例：

• 把这份录音整理成会议纪要，并列出每个人的待办
• 对比这 5 家竞品最近三个月的融资、产品和定价
• 根据这份需求文档，生成研发排期和风险清单

别让用户学习怎么用 AI。产品应该主动教会他。

2. 过程必须看得见

Agent 一旦沉默 30 秒，用户很容易怀疑：卡了吗？死了吗？我的文件传到哪儿去了？

好的过程展示，不是滚一大段“正在思考”。

要展示用户听得懂的动作：

• 正在读取 3 份文档
• 正在提取会议中的待办事项
• 找到 6 条相关资料，准备交叉核对
• 需要你的确认：是否允许创建日历事件？

用户不需要看模型的脑内独白。用户需要安全感和控制权。

3. 关键动作必须让用户确认

查资料、写草稿可以自动跑。

发邮件、删数据、改线上配置、提交代码，这类动作必须停下来确认。

一个实用的判断标准：

这个动作如果做错，用户能不能在 30 秒内轻松撤销？

不能轻松撤销，就加确认。

4. 结果要能编辑、能追溯、能交付

不要只给用户一段 Markdown 长文，然后假装任务完成。

更靠谱的交付方式是：

• 调研结果附来源链接
• 表格可以在线修改
• 邮件可以一键调整语气
• 代码修改能看到 Diff
• 待办可以同步到飞书、Notion 或 Jira

Agent 的价值不在“说得像”，在“交得出去”。

5. 出错时别装懂

工具调用失败，最怕 Agent 一本正经继续编。

直接告诉用户：

• 哪个工具失败了
• 失败原因是什么
• 当前哪些步骤已经完成
• 接下来可以怎么处理

例如：

未能读取第 4 页扫描件，原因是图片分辨率过低。前 3 页内容已经整理完成。你可以重新上传清晰版本，或让我先根据现有内容生成草稿。

这种表达很朴素，却能少掉一大堆信任损耗。

插件可定制化，应该放在什么位置？

插件很重要。企业用户尤其离不开插件。

没有 CRM、知识库、审批流、数据库和内部系统的连接能力，Agent 很容易沦为高级聊天框。

问题在于，插件不是越早越多越好。

产品冷启动阶段，过度开放配置会制造两个麻烦：

• 新用户被权限、字段映射、工作流配置劝退
• 团队不知道用户真正需要什么，只收获一堆杂乱需求

更稳的路径是：

1. 内置少量高频工具：文件、网页、邮件、日历、表格。
2. 围绕一个场景做深连接：例如销售 Agent 优先接 CRM 和邮箱，不要急着接 50 个无关工具。
3. 把高频操作沉淀成模板：让用户一键复用，而不是每次从零配置。
4. 用户量起来后再开放扩展能力：提供插件 SDK、MCP 接入、企业级权限和自定义工作流。

先让用户把事情办成，再讨论让高级用户把系统玩出花。

这顺序不能反。

一套能落地的产品验证方法

如果你正在做 Agent 产品，可以用这个小闭环验证方向。

选 20 个目标用户，不要一开始就盯下载量

找同一类角色的人。

比如 20 个销售、20 个运营，或者 20 个投研分析师。角色越聚焦，反馈越有用。

让他们连续使用 7 天，观察三类数据：

• 任务完成率：发起的任务里，有多少拿到了可用结果？
• 人工接管率：用户在哪一步开始自己动手？
• 次日留存率：第二天还会不会打开？

再补一条很狠的问题：

如果明天这个产品不能用了，你会不会觉得麻烦？麻烦在哪？

用户如果回答“没事，我换个聊天工具问问”，说明你的产品还没有卡进工作流。

用户如果说“那我明天的客户跟进得自己写半小时”，这才是信号。

常见坑：很多 Agent 产品死在这些地方

把 Demo 当产品

演示时能完成一次，不等于用户能稳定完成一百次。

Demo 追求惊艳。产品追求稳定、可控、可恢复。

工具接得太多，核心任务却没做好

首页写着“支持 86 种工具”，用户点进去连一份会议纪要都整理不利索，这就很尴尬了。

只优化模型分数，不看任务成功率

模型回答更聪明，不代表用户更省事。

盯住端到端任务成功率。用户任务完成了，模型能力才算兑现。

把用户反馈当成一句“回答好不好”

点赞、点踩太粗糙。

更有价值的是记录：用户修改了什么、拒绝了什么、在哪一步退出、什么结果被导出了。

自动化越权

Agent 替用户发错一封邮件，前面攒下的信任可能一秒归零。

高风险动作加确认、保留日志、支持撤销。别拿用户的工作事故测试产品能力。

写在结尾：模型只是起点，任务闭环才是护城河

模型厂商做 SDK，能获得开发者分发，也能快速放大调用量。

可真正能沉淀用户关系、行为数据和产品壁垒的，是一个被用户放进日常工作流的 Agent Harness Product。

你可以把目标定得更具体一点：

不要只让用户说“这个模型真聪明”。

要让用户在下班前说：“幸亏有它，不然我今天又得晚走一小时。”

这句话，才是 Agent 产品最值钱的指标。