产品案例研究

看案例不是为了抄功能，而是看它们在「能力、信任、成本」之间怎么取舍。四类产品的架构差异，比界面差异更值得研究。

#四类形态

#编码 Agent

产品形态：IDE 内联补全、聊天式修改、终端里的自主 Agent。

关键设计：

• 上下文以「当前文件 + 相关符号 + 最近 diff」为主，而不是整个仓库；
• 修改以 diff 呈现，人可逐块接受；
• 命令执行有权限模式（只读/需确认/自动）；
• 测试与编译作为验证信号；
• 失败可回滚（git）。

商业教训：

• 开发者愿意为「少打字」付费，但更愿意为「少调试」付费；
• 信任来自可控：能看 diff、能撤销、能限制权限；
• 最成功的产品往往深度嵌入现有工作流（IDE、终端、PR），而不是另开一个聊天框。

可借鉴：把「验证」做进产品循环。能运行测试的 Agent，比只会生成代码的 Agent 可靠一个量级。

#深度研究

产品形态：输入一个问题，几分钟后给出带引用的报告。

关键设计：

• 先澄清/拆解，再并行检索；
• 证据表与引用编号；
• 报告结构固定（结论、发现、来源）；
• 明确标注不确定与冲突；
• 流式展示进度（「正在阅读第 4 篇」）。

商业教训：

• 用户愿意等几分钟，但要知道它在做什么；
• 引用是信任的核心，错误引用比没有引用更伤；
• 成本高，通常需要订阅制或额度制；
• 通用研究容易被平台内置功能替代，垂直领域（法律、金融、学术）更有壁垒。

可借鉴：进度可见 + 引用可点 + 不确定性显式表达，是长任务产品的三件套。

#客服 Agent

产品形态：嵌入在线客服/工单系统，自动回答或辅助人工。

关键设计：

• 知识库 + 订单系统 + 政策库；
• 分类与路由；
• 置信度低/高风险转人工；
• 回复带引用，人工可编辑；
• 严格权限与审计。

商业教训：

• 按「解决的工单数」计费比按 token 计费更容易被接受；
• 客户最怕「错误自动回复」，所以厂商强调 guardrails 与人工接管；
• 集成能力（CRM、工单、订单）比模型能力更能决定落地；
• 上线周期长，需要与业务共同定义边界。

可借鉴：把「不回答」设计成一种正确行为。转人工不是失败，是风险控制。

#Copilot

产品形态：在文档、邮件、表格、会议里提供建议，由人确认。

关键设计：

• 输出是建议，不是动作；
• 上下文来自当前文档/邮件/会议；
• 一键插入、改写、总结；
• 权限继承现有系统；
• 低延迟，几乎实时。

商业教训：

• 分发渠道决定采用率（Office、Notion、IDE）；
• 「帮我开始」比「帮我完成」更容易被接受；
• 用户不愿意为「可能出错且要检查」的功能付费；
• 信任靠长期稳定的质量，而不是一次惊艳的演示。

可借鉴：先做「建议」，再做「执行」。让用户在低成本场景里建立信任。

#共性架构

差异主要在：

• 上下文从哪来（代码库、网页、工单、文档）；
• 验证信号是什么（测试、引用、政策、人工）；
• 输出如何呈现（diff、报告、回复、建议）；
• 控制权如何分配（自动、审批、建议）。

#真正决定采用的不是模型

1. 分发：是否在用户已经工作的地方；
2. 信任：是否可撤销、可审查、可限制；
3. 集成：是否能访问真实数据与系统；
4. 延迟：是否打断心流；
5. 计费：是否与价值对齐；
6. 合规：数据能否使用、能否审计。

模型能力是入场券，不是护城河。

#失败教训

#可以借鉴的做法

• diff/引用/草稿：让输出可审查，而不是一个黑盒答案；
• 分级自主：读自动、写确认、高危禁止；
• 进度可见：长任务展示步骤与当前状态；
• 失败可恢复：保留草稿、支持重试、可回滚；
• 人在环里：把人工放在最有判断力的节点，而不是最后兜底；
• 按价值计费：解决工单、节省时间、完成研究，而不是 token。

#小结

• 四类产品的共性：上下文、模型、验证、呈现、控制。
• 差异在验证信号与输出形态，不在「用了哪个模型」。
• 采用率由分发、信任、集成、延迟、计费、合规决定。
• 最值得抄的是可控性与验证闭环，而不是功能列表。
• 演示成功不等于生产可用，真实数据评估是底线。

下一篇进入参考区：失败模式排查手册。