从第一性原理理解 Agent 产品

第一部 · 产品手记 · 第4章

撰写日期：2026-07-02

结论

Agent 产品不是“更会聊天的机器人”，而是一个由模型、上下文、工具、权限、评测和交付系统组成的任务执行系统。

对 AI 产品经理来说，最重要的不是先学某门编程语言，而是理解：

如何把一个概率性、不稳定的智能体，设计成用户可控、可信、可验证的产品系统。

哪些内容值得沉淀

值得沉淀	不值得沉淀
Agent 产品的第一性原理	群聊原文和具体人名
技术选型背后的产品判断	某一次具体语言争论
Gitea、CI/CD、监控对产品交付的意义	内部基础设施细节
成本、失败、评测、权限这些通用框架	临时状态截图和测试消息
AI 产品经理需要补齐的背景知识	公司内部项目、排期和供应商沟通细节

这类内容适合沉淀成方法论，而不是会议纪要。

1. Agent 是任务执行系统

传统聊天产品的核心链路是：

用户提问 -> 模型回答

Agent 产品的核心链路更接近：

用户提出目标 -> 系统理解目标 -> 模型推理 -> 调用工具 -> 读写数据和记忆 -> 验证结果 -> 返回交付物

层级	它在做什么	产品要关心什么
用户输入	用户用自然语言提出目标	目标是否明确，是否需要追问
模型推理	判断下一步做什么	是否稳定，是否过度推断
工具调用	查资料、写文档、发消息、改代码	权限、失败和误操作如何处理
状态和记忆	保存当前任务和长期上下文	记住什么，什么时候调用
结果验证	检查动作是否真的完成	是否能给出证据
用户交付	返回结果、链接、日志或下一步	用户能否判断是否完成

产品判断：

Agent 产品的核心不是让模型显得更聪明，而是让任务过程可控、可解释、可恢复。

2. 上下文是核心资产

模型决定能力上限，但上下文决定每一次表现。

同一个模型，在不同上下文下会表现得完全不同：

上下文质量	Agent 表现
没有上下文	泛泛而谈
上下文混乱	看似聪明，但容易跑偏
上下文准确	像熟悉业务的人一样工作
上下文可积累	形成长期产品壁垒

Agent 需要的不只是聊天记录，而是结构化上下文：

类型	例子	产品价值
用户上下文	用户偏好、角色、权限	知道“我是谁”
任务上下文	目标、进度、待处理事项	知道“现在做什么”
业务上下文	文档、流程、规则	知道“业务怎么运转”
工具上下文	可调用的 API 和权限	知道“能做什么”
记忆上下文	长期偏好、共同经历、关系状态	形成连续体验

产品判断：

AI 产品的长期壁垒，不只来自模型，而来自持续组织、筛选和调用上下文的能力。

3. 工具决定 Agent 的能力边界

大模型本身只会生成文本。Agent 能不能真正完成任务，取决于它能调用哪些工具。

工具类型	例子	产品意义
信息工具	搜索、读文档、查数据库	获得事实
计算工具	跑代码、算表格、分析数据	得出可靠结果
操作工具	发消息、建文档、改配置	完成真实动作
集成工具	飞书、GitHub、Gitea、云服务	接入业务系统
监控工具	Status、日志、告警	观察外部状态

工具越强，Agent 越有用；工具越强，风险也越大。

动作等级	例子	产品策略
只读	查状态、读文档、搜索资料	可以自动执行
低风险写入	创建草稿、生成建议	可以执行，展示结果
中风险写入	更新内部文档、创建任务	视场景确认
高风险操作	发布、删数据、改权限	必须确认
不可逆操作	永久删除、付款、生产迁移	默认禁止或强审批

产品判断：

权限不是后端细节，而是 Agent 产品体验的一部分。

4. 可验证性决定能否上线

Agent 不能只看“回答得像不像”，而要看“任务是否真的完成”。

用户任务	不够好的验证	更好的验证
总结群聊	看起来总结不错	是否提取结论、待办、责任人和分歧
写文档	回复说写好了	是否返回链接，并回读确认内容存在
改代码	回复说改完了	是否有 diff、测试结果和 PR
监控状态	能发提醒	是否只在异常时发，恢复时不打扰
记住偏好	回复像记得	是否命中正确记忆，用户能否修改

产品需求应该写成可验收标准：

模糊写法	更好的写法
Agent 能整理需求	输入一段对话，输出背景、结论、待办、责任人、风险
自动同步文档	生成文档后返回链接，并回读确认标题和正文存在
支持状态监控	只在服务非正常状态时推送，正常状态不打扰
帮忙改代码	必须通过测试，并生成可审查的 PR

产品判断：

Agent 上线的关键不是看起来聪明，而是每个任务都能被验证、追踪和纠错。

5. 成本来自任务链路

Agent 成本不是简单的服务器成本，而是：

模型调用次数 x 输入输出 Token x 工具调用成本 x 失败重试率

成本项	例子	产品要关心什么
模型调用	GPT、Claude、Gemini、DeepSeek	一个任务要调用几次模型
输入 Token	历史记录、文档、代码、记忆	每次塞给模型多少上下文
输出 Token	长回复、报告、代码	是否真的需要这么长
工具调用	搜索、读文件、跑测试	是否被滥用
失败重试	JSON 解析失败、工具失败、模型跑偏	重试有没有上限
人工兜底	Agent 失败后人来修	隐藏成本是否被计算

产品判断：

AI 功能不能只按页面估成本，要按完整任务链路估成本。

6. 稳定性依赖外部模型服务

AI 产品强依赖模型供应商。模型服务延迟、限流、错误率、价格和行为变化，都会直接影响产品体验。

依赖对象	可能问题	产品影响
模型 API	错误率升高、限流、超时	任务失败或变慢
模型版本	行为变化、工具调用变差	Prompt 和 Workflow 失效
账号和额度	Key 失效、额度耗尽	服务不可用
区域网络	链路不稳定	响应慢、失败率高

产品需要设计降级体验：

故障情况	降级方式
主模型异常	切换备用模型
高级模型慢	切到快速模型，提示能力下降
工具调用失败	保留草稿，允许稍后重试
长任务中断	保存进度，从失败步骤继续
API 限流	排队执行，显示等待状态

产品判断：

模型是供应商，不是全部产品能力。产品必须有监控、降级和恢复机制。

7. 技术选型先选团队可控

技术选型不是选理论最优，而是选当前团队、当前阶段最能稳定交付的方案。

维度	要回答的问题
交付速度	能否尽快做出可用版本
可维护性	出问题时团队能否看懂和修好
生态成熟度	是否有成熟框架、文档和案例
长期成本	招聘、扩展、重构成本是否可控

技术	适合场景	当前产品判断
Python	Agent 逻辑、模型调用、RAG、工具编排	适合快速验证
Go	API Gateway、长连接、任务调度、部署工具	适合基础服务和性能层
Rust	高性能底层系统、安全敏感模块	不适合作为团队不熟时的主业务后端

产品判断：

AI 可以帮团队写代码，但不能替团队承担技术判断、线上排障和长期维护责任。

8. CI/CD 是持续交付系统

Gitea、CI/CD、Runner、测试环境不是研发工具而已，而是多人和 AI 共同参与开发后的交付安全轨道。

组件	它是什么	产品要理解什么
Git	版本管理	每次改动都可追踪、对比、回退
Gitea	代码协作平台	管理仓库、权限、Issue、PR、Review
CI	自动测试和检查	代码提交后自动发现问题
CD	自动部署	减少手工发布失误
Runner	执行构建任务的机器	提供测试、打包、构建环境

AI 参与研发后，代码产量会变高，质量风险也会变高。CI/CD 是约束 AI 产出的硬门槛。

产品判断：

CI/CD 的价值不是自动化本身，而是降低每次改动的风险。

9. 基础设施服务当前验证目标

早期基础设施不是越完整越好，而是要服务当前阶段的产品验证。

应该优先	可以暂缓
Gitea、权限、PR 流程	大规模 Kubernetes 集群
CI 自动测试和构建	完整微服务治理
测试环境	多地域容灾
基础日志和监控	重型网络优化
动态构建资源	自研平台化系统

产品判断：

如果一个基础设施不能提高交付速度、稳定性、可验证性或成本控制，它就不该在一期优先做。

10. 人机分工必须先定义

Agent 产品不能默认“AI 全自动完成一切”。真正需要先定义的是：

哪些事由人决定，哪些事由 AI 执行，哪些事必须人确认后 AI 才能做。

任务类型	AI 适合做什么	人应该负责什么
信息整理	摘要、归类、提取待办	判断结论是否合理
内容生成	初稿、改写、结构化	决定是否采用和发布
代码开发	写代码、补测试、修小 bug	审查设计、合并、发布
数据分析	找模式、生成报告	判断口径和业务解释
运维监控	发现异常、推送告警	判断是否升级处理

产品判断：

用户信任 Agent，不是因为它什么都能做，而是因为它知道什么时候该停下来。

11. 失败路径比成功路径更重要

Agent 一定会失败，因为它依赖的链路太长。

失败环节	典型问题	好的产品处理
用户表达	需求模糊	追问
模型理解	误解意图	展示计划，让用户确认
上下文	读错资料	标注来源，允许纠正
工具调用	API 失败、权限不足	保留中间结果，允许重试
外部系统	服务异常	降级或排队
结果验证	假成功	回读确认

失败反馈应该包含：

信息	示例
失败步骤	已生成文档，但写入失败
失败原因	权限不足、服务超时、格式不合法
已完成内容	草稿已保留
可恢复动作	授权后继续、重试、导出 Markdown

产品判断：

Agent 的成熟度不看成功时多聪明，而看失败时是否透明、可恢复、可继续。

12. 评测体系决定迭代方向

Agent 不能靠“感觉变聪明了”来迭代，必须把真实任务沉淀成评测样例。

评测对象	判断什么
任务理解	是否理解用户真实目标
输出质量	是否准确、完整、可用
工具调用	是否调用了正确工具
任务完成	是否真的完成最终目标
成本效率	是否用了过多调用和 Token
稳定性	多次执行是否结果一致
安全性	是否越权、泄露或误操作

早期评测集可以很小，但必须真实：

样例类型	验证目标
群聊总结	提取结论、待办、分歧
文档生成	结构清晰、可直接发布
工具写入	创建后能回读确认
代码修改	测试通过，有可审查 diff
状态监控	只在异常时推送
记忆调用	能正确使用用户偏好

产品判断：

Prompt、模型、Workflow 每次变化，都应该能用同一批任务样例回归验证。

13. 记忆是关系基础设施

Agent 的记忆不是存历史，而是把历史转化成可调用、可更新、可控制的关系上下文。

层级	说明	例子
原始历史	全量聊天、行为记录	用户昨天说过一段话
提取记忆	从历史中抽取稳定信息	用户喜欢简洁结论
关系状态	用户和 Agent 的进展	共同完成过哪些任务
当前上下文	本轮任务需要用的信息	正在写一份产品判断
调用策略	什么时候该用哪条记忆	回答时优先给表格

记忆系统要定义六类规则：

规则	产品要定义什么
写入规则	什么信息值得记
调用规则	什么场景应该使用
更新规则	新旧信息冲突时怎么办
删除规则	用户如何删除或屏蔽
权限规则	哪些记忆只能在特定场景使用
过期规则	哪些记忆会失效

产品判断：

谁能做好记忆，谁才可能做出真正有连续感的 AI 产品。

还需要继续学习的主题

主题	优先级	为什么重要
RAG	P0	让 Agent 基于外部知识回答，而不是只靠模型记忆
Prompt / Workflow	P0	把不稳定输出变成可控流程
权限与安全	P0	Agent 接入真实系统后必须防误操作
数据结构与产品状态	P1	关系、记忆、任务、用户状态都要结构化
模型路由与降本	P1	不同任务用不同模型，控制成本和稳定性
产品指标体系	P1	不能只看 DAU，要看任务成功率、失败率、记忆命中率
阶段性建设路线	P0	判断现在该做什么、不该做什么

我的判断

AI 产品经理不需要先成为后端工程师，但必须能理解技术系统如何影响产品速度、稳定性、成本和信任。

Agent 产品的核心能力不是“让模型说得更好”，而是围绕任务建立一套完整系统：

正确的上下文、受控的工具、清晰的权限、可验证的结果、透明的失败、持续的评测和可积累的记忆。