Connections · 连接层 · 让 AI 在真实世界里行动
它回答的问题: 你的 Agent 怎么触达真实系统? 它在哪: MCP Server / CLI / Direct API,接邮件、日历、Slack、Jira、Salesforce、数据库等。 它读取的时机: agent 判断需要外部信息或要执行外部动作时。
原文金句
★ 「The risk scales with the capability.」 「风险随能力线性放大。」 (#295,
00:20:17,662 → 00:20:27,668)
★ 「I want to encourage you to start as much as possible with a readonly access.」 「我建议你尽可能从『只读』(read-only)开始。」 (#289)
它在解决什么真问题
前面 4 层让 AI 「更懂你」。 Connections 让 AI 「真的能做事」 — 而不是只能告诉你「你应该这样做」。
但这一层是 7 层里风险最高的, 因为这是真实世界产生不可逆后果的地方:
- 一封发出去的邮件
- 一个被加进同事日历的会议邀请
- 一条贴到 Slack 公开频道的消息
- 一行写进 Jira 的评论
三种连接方式 (#281-284)
| 方式 | 适合场景 | 控制力 |
|---|---|---|
| MCP(Model Context Protocol) | 标准化、跨工具、已经有 500+ 个公开 server | 高 |
| CLI 工具 | 把判断权下放给 agent 自己 | 中(由 agent 自己决定 invoke 顺序) |
| 直接 API / 脚本 | 最灵活, 但你自己写 | 最高 |
✅ MCP 是 7 层里收敛最彻底的层。 spec 版本 2025-11-25。 公开 server 注册表 modelcontextprotocol/registry 已 6,788 stars。 所有主流 agentic 工具(Claude Code / Cursor / Codex / OpenCode / Copilot / Windsurf / Antigravity / Hermes)都支持 stdio + Streamable HTTP 至少两种 transport。
最重要的实操原则:从只读开始
「在让 Agent 写回系统之前,先让它们只读你的日历、只读你的收件箱,不要让它们替你发邮件、加日历事项之类。 写权限应该是你观察 Agent 跑了几周、信任已经攒够之后才加上的。」 (#289-293)
为什么这条很重要 — Nufar 给了一个真实的反例:
「你也可以想象一个 Agent 拿到了公司 Slack 的访问权限, 而权限设置又非常松。 团队里有人开始跟它聊天, 然后这个 Agent 就高高兴兴地把你的私人笔记、你对同事的看法、你正在拟的反馈草稿都分享出去了。 这种事故已经在真实发生, 这些『会传八卦』的 Agent 听上去虽然搞笑, 但对员工隐私构成非常大的风险。」 (#300-305)
给 Chief of Staff 的连接清单(按视频 #309-313 整理)
按权限层级递增:
Level 1 · 最小起步(只读)
- 日历 (Google Calendar / Outlook 只读) → 用于 Pre-read Skill
- 收件箱 (Gmail / Outlook 只读) → 用于 Daily Brief Skill
Level 2 · 个人范围读写
- 个人任务列表 (Things / Todoist / Apple Reminders 读写) → 让它替你跟踪承诺
Level 3 · 草稿先行的写权限
- Slack 发草稿到给自己的 DM 或 saved messages, 你审过再发
- 邮件起草到「Drafts」 文件夹, 你审过再发
Level 4 · (谨慎)对外发言
- 默认不开。 等你跑了几周、信任攒够、流程稳定后再考虑。
Least Privilege(最小权限)清单
「使用最小权限的连接(least privilege)。 如果你要接入任何工作系统, 请先跟你公司的 IT 团队沟通, 别成为公司里下次被拿来当反面教材的人。」 (#306-308)
实操检查清单:
- 这个 MCP / API 我只授予了 agent 实际需要的最小作用域 (例: 只读邮件 =
https://www.googleapis.com/auth/gmail.readonly, 不是 full access) - 这个连接是给我个人用的, 不会被团队其他人通过 agent 侧面访问
- 我知道这个 MCP server 是谁写的(自己写 / 信任的开源 / 厂商官方), 不是随手 npm install 的
- 我有审计日志 — 至少能看到 agent 在过去 24 小时调用过什么工具
- 公司账号的 OAuth 我先跟 IT 沟通过了, 没有自己偷偷连
落地步骤(给你今天的 45 分钟)
Step 1 · 找一个高频只读连接(15 分钟)
挑一个你最常让 agent 「告诉我」 的真实数据源, 优先选只读版本。 例如:
- 日历(只读)
- 你昨天的承诺笔记
- 项目 Notion / Confluence(只读)
Step 2 · 配 MCP server(20 分钟)
按你的工具的 MCP 文档配:
- Claude Code:
~/.claude/settings.json加mcpServers段 - Cursor: 设置面板 → MCP → Add server
- Codex: settings 加 MCP 配置
如果用现成的 MCP server, 优先选 modelcontextprotocol/servers 官方仓库里的实现 — 那里的代码是 reviewed 过的。
Step 3 · 跑 1 个简单查询验证(5 分钟)
让 agent 用这个 MCP 查一条信息(「我下周二有几个会议?」), 确认连接通了。
Step 4 · 设置审计(5 分钟)
打开你工具的 hooks / logs, 让所有 MCP 调用都被记录。 例:
- Claude Code:
~/.claude/settings.json配PreToolUsehook 写日志 - 否则至少写一行: 「我每周五看一次过去 7 天的 MCP 调用记录」
常见坑
| 坑 | 现象 | 怎么避 |
|---|---|---|
| 一上来就给写权限 | Agent 替你发了一封不该发的邮件 | 严格遵守只读 → 草稿 → 写权限的递进 |
| 装来路不明的 MCP | npm install 一个陌生 MCP server, 它读了你的全部邮件 | 只装 modelcontextprotocol/servers 官方或自己审过代码的 |
| 公司账号偷连 | 没跟 IT 沟通就把企业 Slack 接上 agent | 先沟通, 走正规 OAuth 流程 |
| 没有日志 | 你不知道 agent 上周做了什么 | 必须开 PreToolUse / PostToolUse hook |
| 「会传八卦的 Agent」 | 同事跟你的 agent 聊天, 它泄露你的私笔记 | 个人 agent 不要对其他人开放对话入口 |
🟢 译者点评
🟢 MCP 是这一波 agent 工具收敛最成功的标准。 比起 Identity 文件还在 CLAUDE.md / AGENTS.md / Soul.md 三个名字里跳, MCP 是真的「写一次, 跨工具用」。 这一层投资 ROI 极高 — 你今天写一个个人 MCP server, 5 个工具里都能用。
🟢 「会传八卦的 Agent」 这个例子被低估了。 这不是假想风险, 是真实的隐私事故。 我有同事在做 Slack agent 时把它接到了团队公共频道, 然后某个同事问 agent 「最近大家对 X 项目什么看法」, agent 把另一个同事在私信里跟它吐过的槽给完整复述出来了。 当事人离职了。 这条规则:个人 agent 永远不要对其他人开放对话入口, 写进 Identity 的 hard rules 里。
🟢 「先跟 IT 沟通」 这一条在中文工作环境一样重要。 中国公司的 IT 政策对 OAuth 第三方应用越来越严, 你绕过 IT 走小路, 出事后责任全在你。 走正规渠道 + 留痕 + 默认只读, 不是繁文缛节, 是自我保护。
🟢 Verification 必须配合 Connections 一起设计。 Connections 给了能力, Verification 防止能力误用 — 它们必须同步搭起来, 不要先开 Connections 不开 Verification。 见下一篇。
🔗 立刻去做
→ 完成上面 4 步, 接通至少 1 个只读 MCP。 然后读 06 Verification · 校验层 — 防止 agent 「自信地错」。
🔗 延伸阅读
- MCP 规范 — 当前权威版本 2025-11-25
- modelcontextprotocol/servers — 官方实现集合
- MCP 2026 路线图 — 包括
.well-known元数据等未来工作 - Anthropic — Effective harnesses for long-running agents — 长跑 agent 的 connection / harness 设计
- 个人 MCP server 案例:claude-obsidian(4,563 stars)、mcp-obsidian(3,625 stars)