Agent Product 101｜02｜Task Surface：任务从哪里进入

核心结论

Agent 产品首先要设计的，不是聊天框，也不是工具列表，而是 Task Surface。

Task Surface 指的是：用户从哪里把任务交给 Agent、以什么形式描述任务、任务绑定哪些对象、Agent 交付什么结果，以及用户如何判断任务是否完成。

如果 Task Surface 不清楚，产品会出现五个典型问题：

• 用户不知道什么任务适合交给它。
• Agent 不知道任务边界在哪里。
• 产品无法判断什么时候应该继续、询问、暂停或结束。
• 输出只能变成一段“我完成了”的总结，而不是可验收成果。
• 评估体系无法落地，因为任务输入和成功标准都不稳定。

所以 Agent Product 的第一个问题不是“模型能不能完成更多动作”，而是：产品是否定义了一个用户愿意委托、Agent 能够执行、系统可以验收的任务表面？

任务不是 Prompt

很多 Agent 产品早期会把任务入口理解成 prompt box。这很自然，因为 LLM 产品大多从对话开始：用户输入一句话，模型生成一段回答；如果接入工具，模型再调用几个 API。

但对 Agent Product 来说，prompt 只是任务表达的一种方式，不是任务本身。

一个真正的任务至少要回答：

例如用户说：“帮我做一个客户反馈分析。”这句话还不足以成为可执行任务。产品需要继续确定：反馈数据在哪里？时间范围是什么？输出是一份报告、表格、Slack summary，还是要写回 CRM？是否允许读取客户个人信息？完成后谁审核？是否自动发送给团队？

这些不是 prompt engineering 细节，而是产品设计问题。Task Surface 的作用，就是把模糊意图变成可执行、可控制、可验收的任务对象。

从真实产品看 Task Surface

不同 Agent 产品的 Task Surface 差异很大。v0、Replit Agent、GitHub Copilot coding agent、Slack AI agents 和 Salesforce Agentforce 并不是把同一个聊天框放到不同地方。它们真正不同的是任务入口、任务绑定对象和交付物。

v0：从 Prompt 到 Project

v0 的入口看起来像 chat，但它承接的不是普通问答，而是应用构建任务。用户更典型的任务是做一个 landing page、dashboard、根据截图生成 UI、把页面接到现有项目、发布到 Vercel。

因此，v0 的 Task Surface 不是单个输入框，而是 chat、project、代码、preview、GitHub、deployment 的组合。它把自然语言意图绑定到一个可持续演化的 project 上。

如果任务只停留在 prompt 层，Agent 的输出就是一段代码，用户还要复制、粘贴、运行、修复、部署。进入 project 层后，输出才可能变成可预览、可修改、可连接 GitHub、可发布的应用对象。

Replit Agent：从 Idea 到 Running App

Replit Agent 的 Task Surface 更接近完整工作区。用户给的是产品想法，但 Agent 运行在云 IDE、文件系统、运行环境、preview、logs、deployment 和 checkpoint 组成的空间里。

这意味着任务不是一次生成，而是一段持续过程：理解应用目标、生成计划、创建文件、运行应用、检查 preview、修复错误、生成 checkpoint、允许回滚、最终部署。

Replit 的 checkpoint 和 rollback 说明了一个重要原则：Task Surface 不只负责接收任务，也要让任务过程可恢复。失败不应该意味着从头再来，产品应该保留阶段状态，让用户能比较、撤销、恢复和继续。

GitHub Copilot coding agent：从 Issue 到 PR

GitHub Copilot coding agent 的启发在于：它没有把 coding task 只放在聊天框里，而是把任务入口放在开发者已经使用的制度中：GitHub issue。

用户可以把 issue 分配给 Copilot。Agent 在仓库上下文中理解任务，创建分支，修改代码，并交付 draft pull request。

这条路径非常产品化：issue → branch → code changes → draft PR → review → merge。PR 可以被 review，diff 可以被检查，CI 可以跑测试，reviewer 可以留言，branch 可以关闭或回滚。

相比“我已经完成修改”的聊天总结，一个 PR 是更成熟的任务交付物。

Slack：从 Thread 到 Workflow

Slack AI agents 展示了协作空间里的 Task Surface。任务往往不是一个人向 Agent 发出的孤立请求，而是出现在 channel、thread、DM、workflow、Canvas 或 approval flow 中。

例如：在客户反馈频道总结本周高频问题；在 incident thread 整理时间线和行动项；在销售频道根据对话生成 CRM 更新草稿；在内部审批流程中请求某个人确认。

这里的 Task Surface 是“Agent 在多人协作上下文中被召唤”。因此产品必须回答：谁能召唤 Agent？回复在 channel 还是 thread？哪些内容公开，哪些需要私聊？多个人同时纠正时听谁的？执行动作前是否需要审批？最终结果写回哪里？

Agentforce：从 Business Topic 到 Action

企业业务 Agent 的 Task Surface 往往不是聊天，也不是 project，而是业务对象。

在 Salesforce Agentforce 这类产品里，任务通常围绕 CRM、Data Cloud、Flow、MuleSoft、权限和 Trust Layer 展开。用户交给 Agent 的可能是处理客户咨询、更新 lead、总结 account 风险、根据 case 生成下一步、调用业务 action、写回 CRM record。

这类任务不是自由文本任务，而是 business topic、business action、governed data access 的组合。个人 Agent 可以从开放式任务开始；企业 Agent 通常必须从受治理的业务对象开始。

Task Surface 的五个组成部分

一个成熟的 Task Surface 至少包含五个部分：Entry、Object、Contract、State、Handoff。

Entry：入口决定任务语义

Chat 适合表达开放意图；IDE 适合围绕当前文件、diff、测试和错误；GitHub issue 天然带有标题、描述、标签、仓库和验收讨论；Slack thread 天然带有多人上下文；CRM record 天然带有业务对象和权限边界。

所以不同 Entry 不只是 UI 差异，而是任务语义差异。

Object：任务必须绑定真实对象

Agent 产品不能只保存一段 prompt。它要知道任务发生在哪个对象上。

“优化一下这个页面”只有绑定到具体 project 和 preview 时才清楚。
“修复这个 bug”只有绑定到 issue、repo、branch、test output 时才清楚。
“更新客户状态”只有绑定到 CRM record 和权限模型时才清楚。

Object 决定 Agent 可以读取什么上下文、调用什么工具、产出什么结果。

Contract：不要让 Agent 靠猜边界

Contract 是任务约定：目标、范围、输入材料、禁止动作、允许工具、风险等级、成功标准、输出格式、审批要求和截止条件。

Contract 不一定以长表单出现，很多可以来自产品默认值：Coding Agent 默认只在当前 branch 修改；App Builder 默认先生成 preview，不直接发布生产；Slack Agent 默认在 thread 回复，不直接广播；CRM Agent 默认遵守对象权限。

好的 Task Surface 会把这些默认契约产品化，而不是让用户每次靠 prompt 重新声明。

State：用户需要状态，不只是日志

状态面向用户理解和控制，日志面向调试。对用户来说，“正在调用第 17 个工具”通常没有意义；“正在运行测试，失败 2 个，准备修复”更有意义。

Task Surface 应该把底层运行过程翻译成用户能判断是否介入的状态。

Handoff：交付物决定能否验收

成熟 Agent 产品不会只输出“完成了”。它会交付现有系统可以继续处理的对象：App Builder 交付 preview、deployment、live URL；Developer Agent 交付 diff、branch、PR、test result；Workflow Agent 交付 approval request、ticket update、status change；Enterprise Agent 交付 CRM record update、case resolution、audited action。

如果最终结果不能被 review、测试、回滚、审批或写回系统，那么它仍然停留在“回答”层。

产品判断表：你的 Task Surface 成熟吗

设计原则

从用户愿意委托的任务开始

不要从“模型能做什么”开始，而要问：用户真的愿意把什么任务交给 Agent？愿意委托的任务通常高频或高耗时、有明确输入输出、可拆成步骤、有可接受失败处理方式、能通过 review 或 approval 降低风险、结果能进入现有工作流。

把自然语言和结构化任务结合

自然语言适合表达意图，结构化字段适合表达边界、对象、权限和成功标准。成熟的 Task Surface 往往是两者结合：conversation starters、task templates、required fields、scope selector、data source picker、output format selector、risk indicator、approval policy、preview before execution。

默认先交付可 review 的中间对象

越接近高风险动作，越应该先交付可 review 的中间对象：App Builder 先给 preview，Coding Agent 先给 diff 或 draft PR，Workflow Agent 先给 approval card，CRM Agent 先给草稿和建议，Personal Agent 对敏感动作请求确认。

为失败设计入口

Agent 产品必须把失败当成常规路径。Task Surface 应该支持澄清问题、部分完成、权限不足、工具失败、外部系统超时、预算超限、用户中途改目标、任务暂停后恢复、回滚到上一个状态。

常见误区

把 Task Surface 做成万能聊天框

万能聊天框看起来灵活，但会把任务边界、输入约束、权限和成功标准全部推给用户。结果是新用户不知道能做什么，老用户反复写同样提示，产品也难以评估任务质量。

把任务模板做成死流程

另一个极端是过度僵硬的表单或 workflow。这样虽然清楚，但会失去 Agent 的价值。稳定边界由产品定义，开放判断由模型完成。

只设计输入，不设计交付

很多产品把重点放在 prompt、starter、template，却没有定义 handoff。Task Surface 必须从输入一直设计到交付：用户从哪里开始，Agent 绑定什么对象，最终交付什么可验收结果。

忽略多人任务

团队和企业任务不能假设一个用户提出、一个用户验收。Slack thread、GitHub PR、CRM case 或审批流程里，可能有多个参与者、权限级别和验收标准。

PM 检查清单

• 这个任务是否有明确成功标准？
• 入口是否贴近用户真实工作场景？
• 任务是否绑定 project、repo、issue、thread、ticket、CRM record 等真实对象？
• 哪些任务边界来自产品默认契约，而不是依赖用户 prompt？
• 用户能否看懂任务状态，并判断是否介入？
• 交付物是否可以 review、测试、回滚、审批或写回系统？
• 失败路径是否被设计，而不是只让用户重新输入？
• 多人任务里，谁提出、谁批准、谁接收、谁负责是否清楚？

小结

Task Surface 是 Agent Product 的起点。它不是把一个输入框放到页面上，而是定义用户如何把真实任务交给 Agent。

好的 Task Surface 会把自然语言意图连接到真实对象：project、repo、issue、thread、CRM record、workflow、deployment、PR、approval、ticket。它会把模糊任务变成带边界的任务对象：有入口、有对象、有契约、有状态、有交付物。

下一篇讨论 Control Plane：如果 Task Surface 定义的是“用户能把什么任务交给 Agent”，Control Plane 定义的就是 Agent 做任务时，用户如何看见、暂停、修改、审批、接管和回滚。

参考资料

• Vercel v0 Docs
• Replit Agent Docs
• Replit: Checkpoints and Rollbacks
• GitHub Docs: About GitHub Copilot cloud agent
• Slack Developer Docs: Building agents for Slack
• Salesforce Agentforce: How it works
• Microsoft Copilot Studio Overview