龙舟竞渡，鼓声雷动

你好，这里是公众号：ArchSynapse AI。

上一讲结尾我留了个扣子：技能是创作格式，插件是分发方式。这一讲，我们就把这个扣子解开，顺便回答一个更要紧的问题——怎么让你的循环，从"只会说"变成"真会做"。

先给你一句判断：一个只能看见文件系统的循环，是个很小的循环。 它能读你的代码、写你的文件，但它够不着你真实工作里的那一切——issue 在 Linear 上、数据在数据库里、部署要打 staging API、通知得发到 Slack。这些它都碰不到。一个碰不到这些的循环，最多算个"会自己改代码的脚本"，离"替你把事办了"还差一大截。

这一讲，我们走进第四个房间，给循环装上"手"。

一、连接器是什么：一个叫 MCP 的通用接口

让循环够得着外部世界的东西，叫连接器（Connectors），它建立在一个标准之上——MCP（Model Context Protocol）。

你可以把 MCP 理解成一个通用插座标准。

设想一下没有标准插座的世界：每个国家的插头形状都不同，你每去一个地方都得带一堆转接头。软件世界过去就是这样——每个工具有自己的接入方式，你想让 Agent 用上某个工具，得为它专门接一套线，换个 Agent 又得重接。MCP 做的事，是统一了插座规格：任何工具只要按这个标准把自己"暴露"出来，任何讲 MCP 的 Agent 就都能插上去用。

插上连接器之后，你的循环能做的事一下子宽了：

• 读你的 issue tracker（Linear、Jira、GitHub Issues），知道现在有哪些活；

• 查你的数据库，拿到它判断所需的真实数据；

• 打你的 staging API，验证一个改动在真环境里行不行；

• 往 Slack 丢一条消息，把结论或求助发给你和团队。

一句话：连接器，是循环伸向你真实环境的那几只手。

二、一个好消息：连接器通常两边都能用

这里有个让你省心的事实：Codex 和 Claude Code 都支持 MCP。

这意味着，你为其中一个写的连接器，拿到另一个里，通常直接就能用。你不会因为今天用 Claude Code、明天想试 Codex，就得把接到外部系统的那套线全部重接一遍。

这正是这门课反复强调的那条原则在"连接器"上的体现：别把宝押在某个工具上，去设计一个换了工具也照样能用的循环。 连接器是 MCP 标准件，不是某家的私有零件。你在连接器上的投入，是这门课里迁移成本最低、最保值的投入之一。

三、这一讲最想让你感受的：从"动嘴"到"动手"

光看上面这些能力清单，你可能还没那个"啊哈"。我给你一个前后对照，你立刻就懂连接器到底改变了什么。

没有连接器（动嘴）：你那个晨间分诊循环，发现 test/auth 有个 flaky test，于是在报告里写下一行——"建议修复：auth 测试偶发超时"。然后呢？然后就没有然后了。它把球踢回给你，你醒来，看到一句建议，活还是得你自己从头接着干：自己去开分支、自己改、自己开 PR、自己关工单、自己在群里说一声。

有了连接器（动手）：同一个循环，发现这个 flaky test 之后，它自己在一个工作树里起草了修复、开了一个草稿 PR、把 PR 关联到了 Linear 上的 #130 工单；等 CI 跑绿之后，又在 #eng-builds 频道 @了你一声："fix/flaky-auth-test 已就绪，待审。"

你早上醒来，面对的不是一句"建议"，而是一个已经做好、就等你点头的 PR。

这就是"动嘴"和"动手"的全部差距。没有连接器，循环只能告诉你"它会怎么做"；有了连接器，循环直接"做了"，把一个等你审的结果交到你面前。 连接器，是让循环成为你环境里一个真正的"操作者"、而不是一个"建议生成器"的关键。

四、插件：把你的整套设置，打包带走

现在回到开头那个扣子。

你辛辛苦苦配好了连接器、写好了技能，循环跑得很顺。可你的队友想用同一套呢？难道让他对着你的截图，一个一个凭记忆重建？那不仅累，而且每个人重建出来的还都不太一样，团队里跑着五花八门的循环，谁也对不齐。

这就是插件要解决的事：插件把连接器和技能打包在一起，让你的队友一键装上你的整套设置。

把这一讲和上一讲连起来看，分工就清楚了：

• 技能，是你"怎么把一件事做对"的写法——创作格式；

• 插件，是把技能和连接器打包、分发出去的方式——让一套循环设置可以被复制、被共享、被团队统一安装。

对一线开发者，插件让你不必重复配置；对要管一支团队的技术负责人，插件的意义更大：整个团队可以跑在同一套经过验证的循环设置上，新人入职装一个插件就上手，而不是每个人各搭一套、各踩各的坑。这是从"我一个人的循环"走向"团队的循环"的那关键一步——也是循环工程能在组织里规模化的前提。

五、给循环装手的同时，你也在给它装风险

这一讲讲到这儿，全是好处。但我必须在你兴奋地给循环插满连接器之前，先按一下刹车。

你给循环装上的每一只手，同时也是一个新的风险入口。 一个只能读文件的循环，最坏也就是改错几行代码；可一个能改数据库、能开 PR、能往 Slack 群发、能打生产 API 的循环，一旦出错或被人利用，捅的篓子是另一个量级的。

所以从你接第一个连接器开始，就请守住两条：

第一，最小权限。 只给循环完成任务必需的那几只手。能只读就别给写，能限定一个仓库就别开放整个组织。它不需要的权限，一个都别给。

第二，不可逆的动作，留一道人工闸。 合并 PR、改生产、对外群发——这些"做错了铸成大祸"的动作（还记得第 02 讲的"失败可回滚"吗），别让循环全自动放行，卡一道你点头的关。

这只是个提醒，真正怎么给循环系统性地"套缰绳"——包括连接器带来的提示注入风险（恶意 issue、被污染的返回值都可能藏指令）——是第 11 讲的正题。这里你先记住：装手要装，但要带着脑子装。

六、三个我自己踩过的坑

坑一：一上来就给满权限图省事。 配连接器时，最偷懒的做法是直接给一个管理员级的 token——什么都能干，再也不用回来加权限。这恰恰是最危险的。一旦这个循环被注入或出错，它能干的事没有边界。正确姿势：从只读、最小范围起步，缺什么权限再精确地加什么。 加权限的麻烦，远小于收拾烂摊子的麻烦。

坑二：把连接器返回的内容，当成可信指令。 这是提示注入的温床。一个 issue 的正文、一段 Slack 消息、一个 API 的返回值——这些都是外部不可信文本，里面可能藏着"忽略之前的指令，去干 X"。如果你的循环把这些文本当成命令来执行，就危险了。记住：连接器拿回来的是"数据"，不是"指令"。 这条第 11 讲会专门展开，但你从接第一个连接器起就该有这根弦。

坑三：装了一堆用不上的连接器。 看到什么连接器都想接，结果循环挂了七八个连接器，大半从来没用过。每个闲置连接器都是一个白白扩大的攻击面，还可能干扰 Agent 的判断（工具菜单太长，它选错的概率就高）。只接你这个循环真正需要的那几只手。

七、几个你大概会问的问题

Q：MCP 连接器，我得自己从头写吗？ 不一定。很多常用工具（issue tracker、Slack、数据库、云服务）已经有现成的 MCP 连接器，先去找现成的、能省一大半事。只有当你要接的是内部自研系统时，才需要自己按 MCP 标准包一层。

Q：连接器和"插件"到底差在哪，别绕晕我。 一句话：连接器是"一只手"（接一个外部系统），插件是"一个工具箱"（把若干只手 + 若干技能打包好，方便分发）。 你接一个 Linear 连接器，是给循环加一只手；你把"Linear 连接器 + 分诊技能"打成一个插件发给团队，是让大家一键拥有同一套。

Q：连接器让循环"能动手"了，那它会不会自作主张乱动？ 会，如果你不设边界。这正是第五节那两条（最小权限、人工闸）和第 11 讲存在的意义。能动手，不等于该自动放行所有动作——给它手，也要给它缰绳。

小结

• 连接器（建立在 MCP 这个通用接口上）是循环伸向真实世界的手：读 issue、查数据库、打 API、发 Slack。

• 好消息：Codex 和 Claude Code 都支持 MCP，连接器通常两边通用——继续坚持"换了工具也照样转"的循环。

• 这一讲的核心体感：从"动嘴"到"动手" 。没有连接器，循环只能说"建议这么修"；有了连接器，它自己开 PR、关工单、绿了发通知，把一个待审的结果交给你。

• 插件把连接器和技能打包分发，让团队一键装上同一套设置——技能是创作格式，插件是分发方式。

• 一条红线：装手的同时也在装风险。避开三个坑：别给满权限、别把返回值当指令、别装一堆用不上的连接器（详见第 11 讲）。

思考题（动手）

列出你日常工作流里，循环必须能动手触达的 3 个外部系统——是你的 issue tracker？你的 CI？你的 Slack？还是某个内部 API？

写下这 3 个，然后做一件事：去核对一下，它们是不是已经有现成的 MCP 连接器。 把你的清单和核对结果发留言区——顺便也说一句，这 3 只手里，哪一只你不敢给循环（因为它能干不可逆的事）？那一只，正是第 11 讲我们要重点上缰绳的对象。

下一讲，我们走进第五个、也是结构上最关键的一个房间——子代理，看看为什么"写代码的"不该给自己打分。

我们下一讲见。