S2 Day 033 · 当产品的用户不只有人，还有 Agent，软件该怎么设计？

最近用 Dot 时（这里的 Dot 可以替换为 Muse 等一众 Personal AI Agent），我开始想一个以前很少认真想过的问题：

如果以后很多事情都先交给 Personal Agent，那软件的 user 还会只有人吗？

比如我自己做的 Roleward，是一个求职工具。

现在的使用方式还是：

我打开 Roleward（如果用站点而不是 skill）；
搜索职位；
看匹配分析；
保存岗位；
更新申请状态。

但如果以后我已经有一个长期了解我的求职 Dot，我可能根本不想每天再打开 Roleward。

我会直接问：

最近求职怎么样？有什么需要我处理的吗？

然后让 Dot 自己去读取 Roleward 的状态、搜索新职位、检查 Gmail，再把真正需要我判断的事情拿回来。

问题来了：

Dot 怎么使用 Roleward？

这个问题也让我终于比较实际地理解了 MCP、Tool、Signal 这些最近很热的概念。

01 不一定所有产品都要做 Agent

看到 Agent 很热，很容易产生一个反应：

我的产品是不是也应该做一个 Agent？

但 Roleward 已经没有必要再变成另一个 Dot。

Dot 可以负责：

理解我的长期目标；
判断现在该做什么；
协调不同工具；
需要时主动回来找我。

Roleward 更适合做另一件事：

让这样的 Agent 可以很好地使用它。

这就是我现在理解的 Agent 和 Agent-ready 的区别。

Agent 自己拥有目标并持续行动。

Agent-ready product 不一定自己有 Agent，它的核心能力可以被外部 Agent 安全、清楚地调用。

02 如果 Dot 要进入 Roleward，它需要一扇门

假设 Dot 想做几件事：

读取我的求职 pipeline；
保存一个新职位；
查看某个职位的匹配分析；
更新 application status。

Roleward 需要把这些能力提供出来，例如：

get_pipeline()
save_job()
evaluate_job()
update_application()

这些就是 Agent 可以调用的 Tools。

但 Dot 怎么知道 Roleward 有这些 Tools？

每个 Tool 要传什么参数？

返回什么？

需要什么权限？

出错以后意味着什么？

这里就进入了 MCP。

可以把关系粗略理解成：

Dot / ChatGPT↓MCP client↓MCP↓Roleward MCP server↓Roleward backend / database

MCP 是双方都遵守的一套通信规范。

ChatGPT 这一侧负责 MCP client；

Roleward 如果希望支持这种调用，可以提供 MCP server。

MCP server 也不一定是什么很庞大的“服务器”。

这里的 server 更接近一个角色：

它负责把 Roleward 可以提供给 Agent 的能力，按照 MCP 的标准暴露出来。

比如告诉 Agent：

我有一个 save_job Tool；
它什么时候适合使用；
需要 title、company、URL；
执行成功会返回 job ID；
这个 Tool 会修改用户数据，所以需要相应权限。

03 那 API 和 MCP 又是什么关系？

Roleward 自己本来就可能有 API。

Web 前端需要读取数据、保存职位、调用 AI 服务，本身已经会和 backend 通信。

API 解决的是：

软件怎样调用 Roleward。

MCP 更偏向解决：

Agent 怎样发现、理解并调用这些能力。

很多时候 MCP server 底下仍然是在调用已有 API。

所以它们不是二选一。

可以理解成：

Agent↓MCP Tool↓Roleward API↓真实的数据和业务逻辑

这也是为什么我现在觉得 MCP 有意思。

它不是又发明了一套“让 AI 更聪明”的东西。

它解决的是很现实的问题：

模型理解了用户想做什么以后，到底怎么进入真实的软件世界把事情做掉。

04 但“能操作”还不够，Agent 还需要知道什么时候操作

这是我自己创建求职 Dot 后才真正感受到的一点。

我原本会觉得：

既然它是 always-on agent，它应该自己持续找新岗位。

实际创建任务时，我还是需要告诉它：

每天检查一次。

原因很简单。

Agent 再聪明，也需要一个 signal 告诉它：

现实世界可能发生了变化。

Signal 可以是：

每天上午 9 点；
收到一封新的 recruiter email；
一个 application status 更新；
一个职位七天没有进展；
CI test failed；
某个指标超过 threshold；
用户刚刚上传了一份文件。

收到 signal 后，Agent 才重新判断：

这件事情重要吗？
现在需要行动吗？
调用什么 Tool？
需要找人确认吗？

所以我现在会把 Signal 看得比以前重要很多。

一个产品如果想被 always-on Agent 使用，不只要回答：

Agent 可以做什么？

还要回答：

发生什么变化时，它应该知道？

05 Agent 也不完全等于普通 User

还有一个以前很少考虑的问题：权限。

如果 Dot 替我更新 Roleward 里的 application status，系统最好知道：

这是 Dot 在 on behalf of Limin 做操作。

Agent 更像一个 delegated actor。

于是产品需要开始考虑：

它能读哪些东西？
能不能写？
哪些 action 需要 human approval？
谁授权了这个 Agent？
这个授权什么时候过期？
发生错误能不能 undo？
以后回头看，能不能知道到底是谁做的？

Agent 能力越强，这些以前容易被当成后台工程问题的东西，越会变成产品体验的一部分。

06 那以后 SaaS 的 UI 会消失吗？

我觉得这个问题要拆开看。

假设未来我几乎不打开 Roleward。

Roleward 仍然需要保存：

职位；
application state；
scoring；
用户数据；
各种 business logic。

减少的可能只是：

用户必须亲自进入 UI，一步一步操作这些能力。

于是同一个产品未来可能同时有两种入口：

Human → UI

Agent → Tools / API / MCP

UI 仍然适合浏览、比较、检查和做复杂判断。

Agent 更适合执行、协调和持续跟进。

具体比例取决于产品。

所以我也不会因为 MCP 最近很热，就把自己所有产品全部 MCP 化。

比如一个主要在本地处理隐私数据的产品，或者一个只在用户明确上传内容以后才工作的工具，就未必需要 always-on Agent 或远程 MCP。

先有真实的 Agent use case，再决定要不要 Agent-ready。

这是我现在会坚持的顺序。

07 如果以后 Agent 也可能成为产品使用者

我现在会多问三个问题：

第一，我的产品真正值得被调用的核心能力是什么？

不要把 UI 每一个按钮都做成 Tool。

Expose 的应该是：

save_job

而不是：

click_save_button

第二，Agent 怎么知道现实发生变化了？

有没有 event、webhook、notification、state change 或其他 signal？

第三，这些调用是否安全、可验证、可追踪？

权限、approval、audit、undo 怎么设计？

这三个问题目前对我来说，比：

“我的产品是不是也应该做一个 Agent？”

更值得先回答。

因为 Personal Agent 如果真的越来越成为用户的入口，我们未必都需要再造一个 Agent。