产品承诺与任务适配

一个智能体产品可能在第一次模型调用之前就已经埋下失败的种子。问题往往始于错误的产品承诺：它说自己能“处理客服”“做研究”“管理我的收件箱”“修复我的代码仓库”或“运行业务”，却没有说明哪些情况符合条件、哪些证据才算完成、哪些操作只是暂存，以及系统出错时会发生什么。

一个流畅的原型很容易让人忽略这一点。在演示中，用户给出清晰目标，数据源可用，工具调用成功，输出令人信服，也没有人会在会后追问谁对结果负责。而在生产环境中，同一个产品会遇到过时的数据、冲突的权限、缺失的上下文、中断的会话、领域异常、无法访问的控件，以及那些合理地认为“智能体做了”就意味着工作已经完成的用户。

因此，产品问题不是：

模型能否一次性完成这个任务？

而是：

针对这些用户、在这些条件下，这个系统能否以足够高的频率和足够安全的方式交付已接受结果，从而让“委托给它”成为一个负责任的产品承诺？

核心论点

只有当任务确实需要系统代表用户进行适应性工作，已接受结果能够被清楚说明，系统局限能够被传达，并且失败后果能够通过产品、技术和运营控制加以限定时，才应作出智能体产品承诺。

产品承诺不是营销文案。它是面向用户的运行声明。它说明系统将尝试哪些工作、完成需要哪些证据、可能行使哪些权限、哪些仍由用户负责，以及系统何时会拒绝、缩小范围或交还控制权。

承诺不需要暴露每个架构细节，但必须足够真实，让用户能够判断是否值得委托。“使用所选文档起草回复”不同于“回复这位客户”；“准备一个供审查的拉取请求”不同于“修复这个 bug”；“查找可能选项并引用来源”更不同于“决定购买哪个供应商”。

从工作本身出发，而非智能体

以人为中心的设计始于理解用户、任务、环境和使用生命周期，然后根据该背景评估设计（ISO 9241-210:2019）。对于智能体产品，这意味着团队在选择交互模式之前，应先描述工作本身：

谁需要这个结果，谁会受到影响；
成功完成后，用户所处的现实会发生什么变化；
任务的哪些部分是重复性的、高度依赖判断的、开放式的、容易出异常的或具有社会敏感性的；
任务之前、期间和之后存在哪些证据；
哪些记录系统、政策、人员和工具约束了这项工作；
当系统出错、延迟、不完整、无法访问或过度自信时会发生什么；
哪些更简单的产品形态能够用更低的不确定性解决同样的需求。

许多有用的 AI 功能并不需要智能体。分类器、提取器、搜索界面、起草工具、确定性工作流、规则引擎、模板或人工服务，可能更诚实，也更有价值。Anthropic 建议从能奏效的最简单方案开始，因为智能体的灵活性会带来成本、延迟和可预测性方面的代价（Anthropic, 2024）。OpenAI 将智能体描述为适用于包含复杂决策、复杂规则和非结构化数据的工作流（OpenAI, 2026）。这些是适配标准，而不是把每个功能都做成智能体的许可。

对工作的描述还应包含用户现有的替代方案。如果当前替代方案是“咨询专家”，产品就必须解释如何保留专业能力、问责和纠错路径。如果当前替代方案只是“填写表单”，智能体可能只会增加成本和不可预测性，而不会增加价值。如果当前替代方案是“协调多个系统，并根据事实变化调整计划”，智能体体验就可能是合理的，因为适应性本身就是价值所在。

定义已接受结果

承诺应指明结果，而非界面：

弱承诺	强承诺
“一个用于报销的 AI 智能体”	“根据已审批的收据准备报销单，标记缺失的政策证据，并在用户审核后才提交。”
“研究任何事物”	“针对一个边界清晰的问题，提供带来源的简报，区分已有引用支撑的结论和仍不确定的判断，并列出未解决的断言。”
“处理客户支持”	“根据既定政策解决符合条件的退款请求，并将有争议或高价值案例升级处理。”
“修复我的代码”	“调查报告中的 bug，准备补丁，运行仓库测试，并呈现差异和失败结果供审查。”
“管理我的收件箱”	“为选定的邮件线程起草回复，并建议归档或后续操作；只发送用户批准过的消息。”

使用生产工程中的术语 已接受结果（accepted outcome）：一个满足明确完成、质量、政策和影响标准的结果。如果产品无法定义接受标准，就无法诚实地声称完成。它仍然可以提供探索、头脑风暴、起草或咨询帮助，但那是另一种承诺。

对于每个支持的任务，应说明：

支持的输入和起始条件；
系统试图交付的结果；
结果如何被验证；
哪些错误是可容忍的、可恢复的或不可接受的；
需要哪些数据、账户、工具和政策；
用户必须提供哪些信息或权限；
系统不会做什么；
系统何时会停止、询问或升级处理；
以及用户最终会收到什么证据。

微软的人机交互论文建议明确说明系统能做什么、做得有多好，以及何时可能会出错（Amershi et al., 2019）。对于智能体，这种清晰度必须覆盖整个委托任务，而不只是下一条回答。

将任务适配作为设计决策

任务适配是用户需求、任务结构、证据、后果以及可行的控制设计之间的匹配。它不是模型基准得分。一个模型可能在通用测试中表现令人印象深刻，但产品可能缺乏对当前客户记录的访问权限、无法将审批绑定到具体操作、无法恢复未知影响、或无法向受影响的人解释不确定性。

使用以下维度进行产品评审：

维度	适配问题	警示信号
需求	用户需要的是工作完成、建议、探索，还是一个更好的界面？	产品加入智能体是因为技术可用，而非工作需要适应性。
任务结构	有意义的步骤是已知的，还是必须根据新的观察信息调整路径？	固定工作流就能覆盖这些情况，但团队更偏爱“智能体”这个标签。
证据	系统能否观察到足够多的当前事实并验证结果？	完成依赖于模型自称“完成了”。
后果	错误、延迟、不完整、有偏见或过度自信的工作会带来什么危害？	同一套界面同时用于琐碎草稿和高风险行动。
可逆性	影响能否在提交前被暂存、撤销、补偿或审查？	产品提供“撤销”，但实际上只能采取新的纠正措施。
权限	谁可以决定、批准、支出、披露、发送、更新或关闭？	用户授予了广泛权限，却未看到具体影响。
用户能力	目标用户能否理解范围和相关证据，足以进行监督？	审查依赖于用户可能不具备的专业知识。
运维	团队能否在此范围内支持延迟、成本、监控、恢复、申诉和事故处理？	演示成功掩盖了人工修复或支持负担。

没有任何单一维度能决定适配性。只读研究任务可以容忍更多路径决策权，因为它的直接外部影响较小。固定退款工作流即使路径简单，也可能需要强控制，因为它的行动权限很高。在医疗、法律、金融、就业或福利场景中，即使模型给出了看似合理的建议，也可能仍然需要专家问责和正式的追索渠道。

在设计界面之前对承诺进行分类

产品形态应遵循任务适配评审的结果：

产品形态	适用场景	产品承诺
信息功能	主要价值在于检索、过滤、分类或提取。	“在声明的限制内查找、组织或标记这些信息。”
起草助手	用户仍然是主要作者或决策者。	“生成候选文本或选项，供你编辑和接受。”
预定义工作流	阶段和异常情况已知，足以编码。	“让符合条件的案例进入这个受控流程。”
带工具的副驾驶	用户指导工作，系统协助执行步骤。	“帮助你执行由你选择并审查的操作。”
智能体型委托	系统必须根据反馈选择并调整路径。	“追求这个有边界的目标，并返回证据、审批请求或异常。”
带 AI 辅助的人工服务	风险、模糊性、伦理或责任要求人员对结果负责。	“支持指定的人类操作员或专家；结果仍由他们负责。”

智能体的合理性在于适应性带来的价值。如果任务主要是填充字段、检索已知记录或遵循稳定的政策规则，工作流可能产生更好的产品。如果任务需要发现什么重要、选择工具、修订计划，并根据不断变化的证据生成产物，那么智能体形态可能更合适。

选择较低自主性的形态并非缺乏雄心。它通常能创造出更清晰的产品：更低的延迟、更明确的责任、更简单的评估、更可预测的可访问性，以及更少的恢复路径。

将承诺写成一个边界

一个好的承诺包含五个部分：

面向谁：
支持的工作：
完成的证据：
权限与控制：
限制与交回：

示例：

面向审查低价值退款请求的支持经理：
系统根据已发布的退款政策评估请求，
从已连接的系统收集客户和订单证据，
准备带有政策理由的决策，
仅在配置的阈值下自动批准符合条件的退款，
并将有争议、证据缺失、高价值或政策例外的案例升级处理。

这段声明让产品、工程、评估和支持团队都知道要测试什么，也给了用户一个心智模型。它明确了领域、金额阈值、证据、行动权限和异常情况。

边界应在三个时刻可见：

委托前： 使用户知道任务是否符合条件。
工作期间： 使状态、审批和拒绝有理有据。
完成或失败时： 使用户能够解释结果。

Google 的 People + AI Guidebook 强调帮助用户形成准确的心智模型、提供反馈并从错误中恢复（Google PAIR）。产品承诺就是第一个心智模型。如果它被夸大，后续的界面细节很难再修复信任。

明确界定不支持的工作

不支持的工作不应在用户投入精力后才被发现。当这些排除项影响安全、质量、成本、合法性或期望时，应明确说明：

不支持的领域、语言、司法管辖区或账户类型；
未连接或非最新的数据源；
产品将起草但不会提交的操作；
需要单独审批或人工服务的操作；
检索或引用信息的时效性窗口；
产品尚未针对其进行评估的用户群体；
影响使用的可访问性或设备限制；
转交至支持、专家审查或拒绝的敏感案例；
以及当政策、权限或证据缺失时产品的行为。

不支持的工作应导致拒绝、缩小范围、移交或选择更安全的产品形态，而非即兴发挥。一个研究智能体可以说：“我可以生成一份有来源的摘要，但我无法判断法律合规性。”一个编码智能体可以说：“我可以准备一个补丁，但我无法部署它。”一个日程安排智能体可以说：“我可以提议时间，但我无法在你连接的账户之外预订会议。”

避免以下承诺模式：

万能动词： 没有范围的“处理”“解决”“管理”或“自动化”；
替代人员： 暗示系统拥有应属于人类或组织的判断权；
隐藏条件： 成功依赖于未披露的干净数据、狭窄案例或人工修复；
基准包装： 用通用模型分数作为产品就绪的证据；
无声权限扩展： 一个起草助手悄然变成提交结果的行动者；
无声学习： 用户工作被保留或重用，却没有明确的记忆承诺；
流畅性即成功： 将最终文本视为完成，而无需环境证据。

使发布范围与证据匹配

最安全的首次发布通常不是一个更弱的产品，而是一个更诚实的承诺。通过以下方式进行收缩：

用户群体具有强反馈和支持能力；
任务切片具有清晰的已接受结果；
只读或仅提议的权限；
可逆或分阶段的影响；
存在证据的语言、地理或领域；
已知的数据源和时效性边界；
在长期自动化之前的较短操作周期；
明确的审查检查点；
以及用于恢复和支持的运营能力。

只有当证据支持更广泛的主张时，才进行扩展。一个宣称“为审查起草计划”的发布，之后可以演变为“执行已审批的低风险步骤”。一个宣称“自动完成你的工作”的发布，则几乎没有空间在不让用户失望的情况下承认现实。

NIST AI RMF 资料强调在整个生命周期内定义上下文、预期用途、影响和风险管理责任（NIST AI RMF Playbook）。产品团队不需要将每次发布都变成正式的风险申报，但他们确实需要一个命名的操作声明、受影响的人员、预期收益、可预见的危害、证据限制和决策负责人。

将承诺与评估和运维联系起来

产品承诺成为评估和运维必须支持的声明。如果承诺说“处理符合条件的退款”，那么评估需要包括符合条件、不符合条件、模糊不清、证据缺失、对抗性和政策例外的案例。如果承诺说“准备一个拉取请求”，那么评估需要包括仓库状态、测试期望、审查质量和失败恢复。如果承诺说“生成一份有来源的研究简报”，那么评估需要包括来源质量、引用准确性、不确定性处理和未支持断言检测。

不要只评估最容易看到的输出。承诺可能需要：

任务级别的成功证据，而不仅仅是答案质量；
权限检查和审批绑定；
控件和状态的可访问性；
拒绝和交还行为；
真实工作负载下的延迟和成本；
工具、模型、网络或用户中断后的恢复；
用户发现植入错误的能力；
以及用于争议、更正和升级的支持流程。

本章不负责评估方法论。它负责给出产品声明，而该声明将由“评估系统”和“质量门槛”章节来度量。当声明发生变化时，评估套件、发布说明、支持脚本和界面文案也应随之改变。

产品示例

研究简报助手

适配性较好：路径取决于发现的来源、矛盾点和范围细化。系统可以生成有边界的产物、引用来源、标记不确定性，并在证据不足时提问。

承诺边界：它总结和结构化证据；它不证明真实性，不取代专家审查，也不为组织做决定。

关键证据：来源出处、发布和访问日期、未支持的断言、已知冲突和未解决的问题。

客户退款智能体

仅对有限情况适配性较好。系统可以观察订单数据、政策规则、客户历史、金额阈值和支付状态。如果权限和幂等性得到强制执行，它可以自动提交低价值且符合条件的退款。

承诺边界：有争议、高价值、可疑、证据缺失或政策例外的案例会被升级处理。审批绑定到具体操作。

关键证据：政策匹配、订单状态、金额、客户沟通、已提交的退款标识符和核对状态。

个人日程安排助手

当用户希望协调日历、偏好和不断变化的可用性时，适配性较好。当消息被发送给其他人，或会议未经审查就被预订时，任务风险会增大。

承诺边界：系统可以提议时间、起草消息，并且仅在已批准的日历和可用性窗口内进行预订。

关键证据：受邀人、时区、冲突检查、消息内容、审批状态和日历写入确认。

通用“做任何事”助手

作为产品承诺，适配性较差。它可能作为探索性界面有用，但支持的任务集过于广泛，无法进行诚实的评估、清晰的权限、可访问的控制和可靠的恢复。

更好的承诺：将其分解为命名的任务系列，每个系列都有自己的已接受结果、限制和证据。

失败模式

演示即承诺

团队基于精心策划的演示承诺一个线上产品。第一批非策划案例揭示了数据缺失、目标模糊、控件无法访问、恢复无支持以及不可见的人工修复。

有能力但任务不匹配

模型可以执行某个步骤，但产品缺乏完成整个结果所需的权限、证据、状态或恢复能力。

万能助手

产品试图接受每一项任务。用户无法知道哪些请求受支持，评估也无法代表所声称的范围。

隐藏的人工修复

系统看似自主，因为有人类在幕后纠正失败。产品承诺隐藏了成本、延迟、责任和支持义务。

不支持的工作令人意外地拒绝

系统仅在用户投入精力后才拒绝或升级处理。范围限制在委托前并不可见。

产品文案超越运维能力

公共页面承诺自动完成，而运行时仍缺乏监控、恢复、移交或配备人员的支持路径。

本手册的判断

在设计智能体循环之前，先写下产品承诺。
用用户语言定义已接受结果和不支持的工作。
将智能体委托与更简单的产品形态进行比较。
使自主性与后果、可逆性、证据、用户能力和运维就绪度相匹配。
以能得到诚实支持的最窄承诺启动发布。
将评估和生产证据视为对有限主张的证明，而非对普遍范围的许可。
当范围扩展时，同步更新承诺、界面、评估套件、支持流程和发布门槛。

检查清单

参考文献及其使用方式

Anthropic, “Building effective agents” - Anthropic 工程文章，支持“能奏效的最简单方案”原则以及工作流与智能体的区别。
Google People + AI Research, People + AI Guidebook - Google People + AI Research 发布的设计网页资源，用于支持心智模型、反馈、控制、可解释性和平稳降级；它不是正式标准，也不是对任何产品的独立验证。
ISO 9241-210:2019, Ergonomics of human-system interaction - 国际以人为中心的设计标准，用于用户、任务、环境和生命周期框架；本章只使用了 ISO 摘要页。
Microsoft Research, “Guidelines for Human-AI Interaction” - 经同行评审的人机交互论文，支持期望设定、能力限制、不确定性、纠正和控制。
NIST AI Risk Management Framework Playbook - NIST 自愿性风险管理网页资源，用于上下文、预期用途、影响和生命周期风险框架；它不是产品设计认证。
OpenAI, “A practical guide to building AI agents” - OpenAI 面向产品与工程的智能体构建文章，用于当前智能体用例标准、移交和人工干预模式。