type
status
date
summary
tags
category
slug
icon
password
公众号
关键词
小宇宙播客
小红书
数字人视频号
笔记
如果你的软件不能被 Agent 调用，基本没有未来
最近我在想一个问题：未来谁是软件最重要的用户？
答案可能不是人类。
Agent 会是软件最高频的用户
现在你打开一个 SaaS 工具，一天可能点几十次按钮，调用几十次 API。但一个 AI Agent 在处理同一个任务时，可能在几秒内就发出几百次请求。
频率差距不是 2 倍、10 倍，是几个数量级。
这意味着：你今天为「人」设计的产品，明天最重要的用户其实是「机器」。
Headless 不是可选项，是生死线
很多软件团队把 headless 能力、API 接入、CLI 工具当成「高级功能」，放在 roadmap 的后面慢慢做。
这个优先级在 Agent 时代是致命的。
想想看：
- 一个 Agent 想帮你整理数据，但你的工具只有 GUI，没有 API → 用不了
- 一个 Agent 想批量执行任务，但你的软件每次都弹验证码 → 用不了
- 一个 Agent 想读取历史记录，但数据锁在你的数据库里没有导出接口 → 用不了
不能被 Agent 调用的软件，在 Agent 时代就像没有移动端的网站在智能手机普及后的命运。
平台的核心竞争力正在重新定义
以前我们说平台的护城河是：用户数据、网络效应、品牌认知。
这些依然重要，但在 Agent 时代，还需要加一条：你给 Agent 提供了多好的操作界面。
具体来说，未来平台竞争力的三个新维度：
1. 可操作的数据
Agent 需要读数据、写数据、查历史、跨时间线对比。
你的数据是不是结构化的？有没有完整的 API？能不能细粒度查询？
锁在 PDF 里的数据、只能人眼看的 Dashboard、没有 export 的报表 —— 对 Agent 来说等于不存在。
2. 细粒度的权限控制
Agent 操作软件不能是「全有或全无」。
你需要能告诉 Agent：「你可以读这个项目的数据，但不能删除；可以发草稿，但不能发布；可以查看财务，但不能转账。」
这需要比现在的 OAuth Scope 精细得多的权限模型。能做到这件事的平台，才能让企业放心地把 Agent 接进来。
3. 清晰的 Guardrails
Agent 会犯错。平台需要提供防护机制：
- 操作日志（Agent 做了什么，随时可以审计）
- 回滚能力（Agent 操作错了，可以撤销）
- 限流和预算（防止 Agent 失控消耗资源）
- 人工审核节点（关键操作需要人确认）
这些不是「体验优化」，是 Agent 接入的前提条件。
谁先做好，谁先赢
现在已经有一些产品在往这个方向走：
- Linear 的 API 和 MCP 接入做得很完整，Agent 可以直接管理 issue
- Notion 开放了数据库 API，但权限粒度还不够细
- GitHub 的 CLI 和 Actions 让它成为 Agent 时代的天然受益者
- Stripe 的 API 设计一直是业界标杆，Agent 调用起来几乎无障碍
反观那些「大而全」但 API 残缺的企业软件 —— 每次 Agent 碰到它们就像碰到了一堵墙。
给产品团队的三个行动建议
1. 今天就给你的产品写一份 MCP Server
Model Context Protocol 是目前 Agent 接入工具最标准的方式。先做一个最小版本，让 Agent 能调用你最核心的 5 个操作。
2. 把「Agent 友好」加入 PRD 评审标准
每个新功能上线前问一句：「Agent 能调用这个功能吗？」如果不能，补上 API 接口。
3. 设计 Agent 专属的权限角色
在你的权限系统里加一个
agent 角色，定义它能做什么、不能做什么，并记录所有操作日志。最后
软件的下一个大分水岭不是 AI 功能有多炫，而是：你的软件能不能成为 Agent 工作流的一部分。
能的，会被越来越多地调用，越来越不可替代。
不能的，会被慢慢绕开，慢慢边缘化。
这个变化不会在一夜之间发生，但方向已经很清楚了。
现在开始做，还来得及。
