上一篇我们分析了 CLI vs MCP 的争论本质上是在讨论管道而真正缺的是水龙头。这篇继续往下挖就算水龙头开了你也大概率接不上。Agent 在现实中寸步难行的原因比大多数人想的更结构化。一个常见的许诺“让 Agent 帮你自动写周报——它去翻你的 Git commit、飞书文档编辑记录、Jira 状态变更、日历会议生成一份你老板能看的周报。”这是 Agent 产品最爱讲的故事。听起来很合理——数据都是你自己的工具也都在用只是把手动汇总的过程自动化了而已。但如果你真的动手试一下会发现 5 个数据源里只有 1 个能用Agent帮你写周报Git log ✅SSH key 在本机直接可用飞书文档 ❌需要创建企业应用 → 管理员审批Jira 工单 ❌IT 部门禁用了 Personal Access Token日历 ❌飞书日历 API 同样需要企业应用审批邮箱 ❌企业邮箱的 IMAP 被安全策略禁用✅ 能拿到❌ 拿不到不是 Agent 不够聪明不是 CLI 不够高效——是数据根本拿不到。当然市面上有一些投机方案试图绕过这个限制用浏览器扩展借用登录态抓取飞书文档、用 RPA 模拟点击导出 Jira 数据、用逆向工程封装企业邮箱接口。这些方案确实能跑通 demo但它们本质上是爬虫——UI 改版即失效、安全策略升级即封杀、法律层面始终存在风险。把工作流建立在这类方案上等于在流沙上盖楼。我们在第三篇会详细讨论这些翻墙方案的现状和局限。这里先聚焦于一个更根本的问题为什么正规途径走不通Agent 的实际能力取决于三个变量Agent 能力 三者的交集LLM 推理能力✅ 2026 年已经足够工具调用效率✅ CLI Skills 基本解决可访问的数据范围❌ 严重不足整个行业在卷 LLM 能力和工具协议但真正的短板是数据访问。就像拥有一辆性能顶级的赛车和一条完美的赛道但油箱是空的。两层壁垒为什么数据拿不到数据拿不到不是一个笼统的问题。它有两层真正的壁垒性质完全不同第二层组织管控第一层平台封锁微信、淘宝、美团、抖音没有开放 API商业模式决定不会开放飞书、Jira、Google Workspace平台有 API但企业 IT 不批准你看得到数据但程序读不到数据到手之后格式不统一LLM 能处理↑ 这不是壁垒是工程摩擦第一层被讨论得最多但实际工作中第二层才是更多人会撞上的墙。第一层平台封锁微信不会做wx auth login淘宝不会开放比价 API抖音不会给你推荐数据。上一篇从技术角度论证了 CLI 完全能实现 OAuthgh auth login就是先例所以这不是技术障碍1。那为什么不做因为数据封锁是这些平台商业模式的根基。Agent 一旦能替用户做最优决策——比价、比评分、跨平台搜索——平台就失去了通过推荐算法引导用户消费的能力。这直接威胁广告和流量变现的核心营收。一个简单的判断标准平台会不会对 Agent 开放取决于开放是否符合其商业利益。平台类型代表对 Agent 开放逻辑卖订阅/服务的GitHub, Notion, Vercel✅ 主动开放越多 Agent 接入 → 用户越依赖 → 更多付费卖流量/广告的微信, 淘宝, 抖音❌ 封锁Agent 帮用户跳过推荐 → 广告价值下降卖企业服务的飞书, 钉钉⚠️ 有限开放Bot 生态丰富 → 企业更依赖平台第二层组织管控——看得到不代表拿得到举个具体的例子你在公司用浏览器打开飞书能看到所有群聊记录和共享文档。现在你想写一个脚本让 Agent 读取同样的消息内容。你会发现需要在飞书开放平台创建一个企业自建应用申请im:message权限然后提交给公司管理员审批发布。管理员可能会问你要这个权限做什么然后拒绝你。你在浏览器里看得到的数据你的程序不一定读得到。因为两者走的是完全不同的认证链路✅ 你有❓ 不一定❌ 大概率没有可视化权限能在浏览器里看到每天都在用API 权限能通过程序化接口提取需要 API Token组织授权公司 IT 允许你调 API安全策略阻止你每天打开飞书看文档、在 Jira 看工单、在邮箱收邮件——这些是可视化权限。浏览器持有登录态Cookie 自动携带一切无感。但 Agent 走的是完全不同的认证链路Agent / API 访问浏览器访问需要需要需要两条完全不同的路径你的浏览器Cookie / Session自动携带服务器返回数据Agent / 脚本API Token / OAuth CredentialIT 部门审批安全策略允许API 服务器你有前者不代表你有后者。Agent 只能走后者。以一个普通程序员非管理员的视角各工具的实际 API 可访问性工具浏览器可看API 可调卡在哪里Git本地✅✅SSH key 在本机无需任何审批飞书文档✅❌创建企业自建应用需要管理员审批2钉钉✅❌同上企业内部应用需要组织管理员授权Jira Cloud✅⚠️取决于公司是否禁用 Personal Access Token企业邮箱✅❌IMAP/SMTP 通常被安全策略禁用Google Workspace✅❌OAuth 应用需要管理员设置白名单Notion个人✅✅个人 Integration 不需要管理员参与3结论很清晰能自由通过 API 访问的基本只有本地文件、个人 Git 仓库和 Notion 个人空间。其余全部卡在组织管理员审批环节。这也解释了一个现象为什么 Agent 目前最成功的应用场景是编程辅助因为代码在你的本地文件系统里不需要任何人的许可。补充数据拿到之后呢有人可能会问就算前两层都打通了数据散落在 Git、飞书、Jira、邮箱等不同系统里格式各不相同——这算不算第三层壁垒坦率地说以 2026 年 LLM 的能力这不构成真正的壁垒。Git log 是文本Jira API 返回 JSON飞书文档可以导出 Markdown——只要是能转为文本的数据当前的模型都能读懂并综合处理。身份映射Git 邮箱 ≠ 飞书 user_id告诉模型一次就够了。时间对齐、语义提取、去重归类这些本来就是 LLM 最擅长的事情。数据格式不统一是工程层面的摩擦不是架构层面的壁垒。跟前两层平台直接封锁、组织不给权限完全不在一个量级上。真正卡住 Agent 的只有两面墙平台不开放和组织不允许。只要数据能拿到手LLM 有能力处理剩下的事情。Agent 实际能力的边界综合两层壁垒以下是 Agent 在 2026 年的真实能力边界场景技术可行实际可用受阻于编程辅助写代码、调试✅✅无壁垒——代码在本地搜索公开信息并整理✅✅无壁垒——互联网公开数据自动写周报✅❌第二层飞书/Jira API 权限跨平台比价机票、酒店✅❌第一层携程/12306 不开放客户关系管理✅❌第二层CRM API 需 IT 审批自动处理邮件✅❌第二层IMAP 被禁用跨平台内容发布✅❌第一层各平台不互通个人健康数据分析✅❌第一层健康 App 不开放技术上全部可行。实际上大部分做不到。结论Agent 帮不了你不是因为它不够聪明。是因为两面墙平台封锁商业模式建立在数据围墙上不会主动开放 API。这是商业博弈问题。组织管控就算平台有 API企业 IT 的安全策略可能不允许你使用。这是组织管理问题。至于数据格式不统一、多系统信息需要整合——以当前 LLM 的能力这只是工程摩擦不是真正的障碍。只要数据到手模型能搞定。问题是数据到不了手。而大部分 Agent 产品的营销只字不提这些直接假设你有 API 权限。下次有人向你推销用 Agent 自动化工作流时不妨先问两个问题这些数据平台提供了 API 吗这些 API我所在的组织允许个人使用吗两个都是 Yes 才能真正落地。在 2026 年的现实中两个都是 Yes 的场景仍然不多。这是 “Agent 生态思考” 系列第二篇。下一篇聊既然数据拿不到那谁在用什么方式绕路阿里的闭环生态、豆包手机的屏幕爬虫、以及什么力量可能最终推动开放。参考资料关于平台数据封锁与商业模式的关系参见 MCP vs. CLI for AI Agents: The Answer Is Both 以及 The MCP vs CLI Debate Is Missing the Point。本系列第一篇从技术角度论证了 CLI 完全能做 OAuth因此平台不开放的原因是商业选择而非技术限制。 ↩︎飞书企业自建应用创建流程需要企业管理员审批参见飞书开放平台文档。普通员工无法自行创建具有im:message等权限的应用。 ↩︎Notion 的 Internal Integration 允许个人用户直接创建无需工作区管理员参与参见 Notion API 文档。这是目前少数支持个人级别 OAuth 的协作工具之一。 ↩︎