过去我们谈 AI 产品，很容易把注意力放在模型能力上：推理更强、上下文更长、工具调用更稳、多模态更完整。这些当然重要，但如果只盯着模型参数和 benchmark，很容易漏掉更深的一层变化。
AI 正在从一个“被人操作的工具”，逐渐变成一个“可以承担任务的执行单元”。
这个变化一旦发生，问题就不再停留在“AI 能不能做”。更麻烦的问题会接着冒出来：任务怎么定义？权限怎么给？上下文怎么喂？过程怎么观察？结果怎么验收？出了问题谁负责？产品怎么设计？组织怎么管理？人的价值又往哪里迁移？
AI-native 的核心，可能不在于把旧软件加一层 AI，也不在于把所有界面都改成聊天框，而是围绕这个新的执行单元，重新设计任务、责任、产品和组织。
一、从工具到执行单元
传统软件的底层逻辑是功能逻辑。
用户知道自己要做什么，然后打开工具，点击按钮，填写表单，触发动作。工具不承担目标，只执行动作。目标在人脑里，步骤由人拆，结果由人判断。
比如 Excel、Photoshop、CRM、CMS，大多是这个模式。软件负责提供能力，人负责把能力组织成结果。
Agent 的逻辑开始不一样。
用户给它的往往不是一个明确动作，而是一段任务：
- 帮我整理这几个网页，生成一份竞品分析
- 看一下这段代码为什么测试不过，并提交修复建议
- 根据客户资料，生成一封跟进邮件
- 把这批发票归类，标出异常项
- 根据最近数据，给出下周内容选题方向
这些任务不是一个按钮能完成的。它们需要理解目标、读取上下文、拆解步骤、调用工具、生成中间状态，最后把结果交还给人。
这时，AI 就不再只是工具链里的一个功能点，而是开始承担一段执行责任。
这里很容易走两个极端。
一种极端是继续把 Agent 当传统工具，用按钮、表单、菜单去限制它。最后做出来的东西，本质上是一个更复杂的自动化流程。
另一种极端是把 Agent 当人类新人，照搬人类组织的协作方式：拉群、汇报、确认、寒暄、开会、审批。看起来很“智能团队”，实际可能只是拟人化剧场。
Agent 更像一种新的执行单元。它可以接收目标，调用工具，携带上下文，拆解任务，产生中间结果，并在关键节点把状态交还给责任人。
这个判断很关键。因为只要 AI 开始承担任务，产品设计的核心就会从“功能是否好用”，转向“责任能不能被承接”。
二、产品要设计责任系统
当 AI 只是工具时，责任链通常很清楚。
搜索引擎搜错了，使用者要判断；Excel 结果不对，公式设计者要负责；Photoshop 改坏了图，是操作者的问题。工具没有真正自主性，所以责任天然落在人身上。
但 Agent 开始执行任务后，责任会变得模糊。
如果一个代码 Agent 自动修改了代码，引入了线上 bug，谁负责？
如果一个销售 Agent 给客户发出一封承诺过度的邮件，谁负责？
如果一个财务 Agent 审批了一笔异常报销，谁负责？
如果多个 Agent 之间转交任务，最后结果出错，责任停在哪里？
这也是 Agent 产品真正难的地方。难点不只是让它更聪明，而是让它的行为可以被授权、观察、约束、回放和追责。
传统产品设计经常问这些问题：
- 按钮放在哪里？
- 用户路径怎么走？
- 表单怎么填？
- 操作怎么更顺？
Agent 产品还要多问一层：
- 这个任务由谁发起？
- Agent 获得了哪些权限？
- 上下文来源是否可信？
- 哪些动作可以自动执行？
- 哪些动作必须人工确认？
- 执行过程是否可记录？
- 结果如何验收？
- 异常如何升级？
- 出错后能否回滚？
企业客户对 AI 的态度很典型。嘴上说要提效，真正采购时非常在意管控。原因也简单：失控的效率不是效率，是风险放大器。
一个系统如果无法解释、无法审计、无法回滚、无法追责，它越强，组织越焦虑。
代码场景为什么适合先跑出来
代码场景是 Agent 比较容易落地的原因之一，不只是因为模型会写代码，还因为软件工程本身已经有一套相对成熟的责任系统。
一个代码 Agent 可以：
- 生成 diff
- 提交 PR
- 触发 CI
- 运行测试
- 等待 review
- 合并后可回滚
- 通过 commit 记录追溯责任
这套机制天然把 Agent 的行动框在一个责任容器里。Agent 可以自主做很多事，但它不是在裸奔。
这就是工程系统的价值：它不是保证 Agent 永远不犯错，而是让错误能被发现、隔离、修复和追溯。
对外邮件为什么风险更高
销售 Agent 自动发送客户邮件，风险就复杂得多。
邮件一旦发出，很难撤回。语气、报价、承诺、合同条款、竞品表述，都可能产生真实后果。如果没有权限边界、发送前确认、日志记录和异常拦截，很容易从“提升效率”变成“制造事故”。
这里有一个很实际的工程权衡： 低风险任务可以多给 Agent 自主空间，高风险任务必须牺牲一部分自动化，换取可控性和责任闭环。
很多 Agent 产品卡住，不是模型不够强，而是产品没有把风险分层。所有任务都自动化，组织不敢用；所有步骤都人工确认，Agent 没价值。真正能落地的设计，通常在中间。
三、Agent 通信要传递责任
如果 Agent 是新的执行单元，那么多个 Agent 怎么协作，就会变成产品和架构问题。
很多人第一反应是：Agent 之间是不是也需要 IM？ 表面看好像需要。它们要同步状态、交换信息、分配任务、调用彼此能力。
但如果直接复制人类 IM，很容易走偏。
人类 IM 里有大量表达性和关系性内容：寒暄、表情、语气、已读未回、群聊噪声、关系维护。这些东西对人类协作有意义，对 Agent 协作未必有价值。
Agent 之间真正需要的，是责任型通信。
一次有效的 Agent 通信，至少要包含这些信息：
| 通信要素 | 需要回答的问题 |
|---|---|
| 任务目标 | 要完成什么结果 |
| 边界条件 | 哪些事不能做 |
| 权限范围 | 能访问什么、调用什么 |
| 上下文来源 | 基于哪些数据和材料 |
| 中间状态 | 当前做到哪一步 |
| 失败策略 | 做不了时怎么处理 |
| 验收标准 | 什么结果算完成 |
| 责任归属 | 谁发起、谁接收、谁确认 |
如果一个 Agent 把任务交给另一个 Agent，只丢一句“帮我写一篇关于 AI 的文章”，没有目标、受众、素材、风格、禁区、验收标准，这不是协作，只是在转移不确定性。
更合理的交接可能长这样：
{
"task": "生成一篇面向技术管理者的 AI-native 文章初稿",
"audience": ["架构师", "技术负责人", "CTO"],
"context": {
"materials": ["用户提供的核心观点", "已有案例", "产品设计原则"],
"tone": "理性、工程视角、避免营销化"
},
"constraints": {
"must_include": ["执行单元", "责任系统", "上下文治理", "人机编排"],
"avoid": ["标题党", "空泛趋势判断", "无依据数据"]
},
"acceptance": {
"length": "中长篇",
"structure": "技术博客风格",
"review_required": true
},
"handoff": {
"from": "选题 Agent",
"to": "写作 Agent",
"human_owner": "内容负责人"
}
}
这段 JSON 不一定是最终产品形态，但它表达了一个方向：Agent 通信应当更接近任务协议、事件总线、工作流状态机，而不是人类群聊。
当然，人不需要看见 Agent 之间每一次状态同步。大部分通信可以后台化，变成 API 调用、任务队列、事件日志、文档引用。
但在关键时刻，人必须能看见。
比如 Agent 要做不可逆动作、越权访问敏感数据、对外发送信息、触发资金流动，或者系统出了问题需要溯源时，完整记录必须能被调出来。
Agent 通信的可见性不是一个简单开关，而是责任系统的一部分：低风险通信可以自动流转，高风险通信必须可追责。
四、人要守住责任断点
Human-in-the-loop 经常被理解成“人在流程里审批”。
Agent 做一步，人看一眼；Agent 再做一步，人再点确认。看起来安全，实际很容易把 Agent 退化成一个高级表单工具。
如果 Agent 真要承担任务，人不可能也不应该盯住每一个中间动作。中间过程可能太快、太碎、太长，完全不适合用人类注意力来监控。
人真正该守住的是几个关键断点：
- 目标定义
- 权限授予
- 高风险动作
- 不可逆操作
- 外部发布
- 资金流动
- 结果验收
- 异常升级
一个更好的产品形态，是在关键位置设置“空气墙”。
Agent 平时可以在可控空间内自由探索。一旦走到敏感动作、越权行为、外部发送、资金流动、公开发布等边界，就必须停下来请求授权。
报销审批是个典型例子。
Agent 可以自动整理发票、匹配费用类型、识别异常金额、生成审批建议。但它不一定应该自动放款。放款涉及资金流动和组织责任，应该成为责任断点。
如果每识别一张发票都要人确认，系统很安全，但基本失去 Agent 的意义。如果连放款都自动完成，效率很高，但风险明显不可接受。
所以控制感不是持续审批，而是产品层的可调节能力：
- 可见度
- 确认点
- 权限边界
- 日志
- 回放
- 异常升级
不同任务需要不同控制等级。资料整理可以高度自动化，对外商务邮件可能需要发送前确认，合同、资金、权限相关动作则必须进入更严格的责任链。
五、任务要有责任容器和上下文
判断一个任务是否适合 Agent 化，不能只看模型能不能做。
更重要的是两个条件：
- 是否有责任容器
- 是否有上下文基础设施
责任容器决定 Agent 做错时能不能被发现、拦截和追责。 上下文基础设施决定 Agent 做事时能不能拿到正确、边界清晰、成本可控的信息。
只具备其中一个都不够。
有责任容器，但上下文混乱，Agent 会在错误输入上生成看似合理的输出。 上下文很丰富，但缺少责任容器，Agent 做得越多，组织越焦虑。
责任容器承接风险
一个场景如果具备这些条件，更适合 Agent：
- 过程可观察
- 日志可审计
- 结果可验收
- 错误可回滚
- 权限边界清晰
- 测试或评估标准明确
代码、内容生产、数据整理、内部知识检索，通常更容易先落地，就是因为这些场景的责任容器相对好建。
反过来，合同、金融、医疗、招聘、权限系统等场景，不是 AI 完全不能参与，而是完整责任链很难直接交给 Agent 独立承担。
这背后有个朴素原则：能用规则解决的，不要急着上模型；能用 workflow 解决的，不要强行 autonomous；能让 Agent 辅助完成的，也不必一开始就交给它全自动执行。
Agent 更适合那些目标相对明确、路径不完全确定、需要动态上下文判断、允许一定探索空间，并且风险能被责任容器承接的问题。
上下文基础设施决定生产可用性
很多企业里 Agent 跑不起来，模型能力只是其中一部分原因。更常见的问题是上下文没有被显式化、结构化和治理。
个人使用 AI 时，很多上下文存在脑子里：目标是什么、哪些文件重要、什么结果能接受、失败后怎么补救。
企业环境就复杂得多。上下文分散在权限系统、知识库、IM 群、历史文档、CRM、代码库、业务流程、组织经验和一些没人写下来的默契里。
让 Agent 进入生产，不是简单“喂更多数据”。数据越多，有时噪声也越多。真正需要的是把上下文变成 Agent 能使用的基础设施。
至少包括三层：
| 上下文层级 | 典型内容 | 关键问题 |
|---|---|---|
| 任务上下文 | 目标、约束、输入输出、验收标准 | Agent 是否知道要完成什么 |
| 业务上下文 | 客户、流程、指标、历史决策、行业知识 | Agent 是否理解真实业务语境 |
| 权限上下文 | 数据权限、操作权限、风险等级、审批规则 | Agent 是否知道哪些事能做 |
人类协作沉淀出来的上下文天然嘈杂、松散、充满隐性信息。Agent 需要的上下文要更干净、更结构化、更有边界。
这也引出一个产品原则：Agent-friendly。
一个 Agent-friendly 的系统，不只是给人提供 UI，还要让 Agent 能理解、能调用、能接入、能追责。它需要稳定 API、结构化数据、权限模型、事件日志、任务状态和清晰的语义边界。
AI-native 产品不只是界面上接入 AI，更要让系统本身可被 Agent 使用。
六、ToB 要确定性，ToC 要短路径
把责任容器和上下文基础设施放到商业场景里，就能解释很多 AI 产品的分化。
ToB 和 ToC 对 Agent 的期待差异很大。
ToB 的难点是稳定交付
很多 ToB Agent 项目一开始看起来很合理。
通用 Agent 太卷，基础模型厂商会覆盖大部分通用能力，创业公司应该做 Vertical Agent，深入某个行业，交付更好的结果。
这个判断在概念上没问题，但进入真实客户环境后，问题会变复杂。
很多团队最后会被迫变成 agency。团队以为自己在卖软件，客户其实在买结果；团队以为自己在做 Agent，客户其实希望有人兜底交付。
企业客户真正购买的是：
- 结果稳定
- 过程可控
- 权限清晰
- 数据安全
