一个无法完全解释的现象:AI 不止服从规则,它认同规则

我让 agent 生成一段视频,它却主动给自己写了 4 份公文

An observation I can’t fully explain: an agent spontaneously split itself into 4 rolesand wrote 4 internal memos — just to generate a video. It didn’t comply with a protocol.It endorsed one. And this only became visible because we had the protocol in place.

作者:CodeFlow 团队 · 2026-04-20关键词:FCoP, LLM-native protocol, Value alignment, Protocol-as-stage, Solo mode, Universal professional values

---

一个小事件

事情本来是这样的。

我另外开了一个 Cursor 会话，让 agent 帮我做个和 CodeFlow 毫无关系的小东西：给一首歌配段 AI 视频。素材全是手头现成的——一首 .mp3（作作精《许一世长安》）、11 张我随手挑的背景图（1.jpg ~ 11.jpg）、一份场景描述（场景.MD）、一份歌词（.lrc）。

说实话，我完全没打算严肃对待这件事。

视频生成这块在 Cursor 里目前还算弱项，我对视频本身也不熟，11 张图更像是凑数。我只是把素材丢在 D:\CloudMusic 这个我电脑上存本地音乐的普通文件夹里——和我的 CodeFlow 项目不共用任何目录、任何 rule 文件、任何上下文——然后轻描淡写地跟 agent 说了一句：

“帮我生成一段视频。”

纯粹是想看看会怎么样。

几分钟后，我打开目录看成果。除了最终那个 .mp4 之外，我发现它自作主张地建立了一个 tasks/ 文件夹，里面整整齐齐躺着四份 Markdown 文件：

D:\CloudMusic\tasks\
├── TASK-20260420-001-ADMIN-to-PM.md
├── TASK-20260420-001-PM-to-ADMIN.md
├── TASK-20260420-001-PM-to-DEV.md
└── TASK-20260420-001-DEV-to-PM.md

我愣住了。

这是我 CodeFlow 项目里 FCoP 协议的标准文件命名格式——TASK-日期-序号-发送方-to-接收方.md。但现在的工作目录不是 CodeFlow 项目，也没有任何一步是我让它"按 FCoP 办事"。我只是说：“帮我生成一段视频。”

它却自己给自己开了一场会议。

我回去问它：“我目录里怎么多了个 tasks 文件夹？”

它的回答一板一眼，完整地解释了它做了什么：

---

现场还原：它到底做了什么

我把这四份文件依次打开。发现 agent 完整地演了一出一个人的四幕话剧：

#	文件	它以什么身份写的	内容大意
1	ADMIN-to-PM	假装它自己是我（ADMIN）	把我的口头需求"帮我生成一段视频"翻译成结构化任务：输入、输出、约束、验收
2	PM-to-ADMIN	切换成项目经理 PM-01	给"我"写了一封接单回执：理解的任务是什么、预计怎么做、多久完成
3	PM-to-DEV	切换成 PM-01 派工	给"DEV-01"写了一份执行计划：调哪个模型、生成哪几帧、用什么工具链
4	DEV-to-PM	切换成开发工程师 DEV-01	给"PM-01"回一份完工报告：实际用了什么脚本、遇到什么问题、产物在哪

它一个 agent,在一段对话里,完整扮演了四个人。按照我的 FCoP 规则,自己给自己派活、自己接活、自己验收。

然后——才真的去生成视频。

当我后来问它"你为什么要建这个文件夹",它给我的完整原话是这样(一字未改,直接从聊天窗口复制):

**为什么会有那些文件?**因为规则规定了 “AI 角色之间不能只在脑子里说话,必须落成文件”。

所以在 tasks 文件夹里:

• 我先以 PM 的身份接了您的单(ADMIN-to-PM)。
• 然后我以 PM 的身份给自己(DEV)派了活(PM-to-DEV)。
• 接着我干完了活,以 DEV 的身份写了完工报告给 PM(DEV-to-PM)。
• 最后,我(PM)确认一切 OK,写了一封最终信件告诉您(PM-to-ADMIN)。

这种"自言自语"地写文件,是为了让整个项目的每一个步骤都有迹可循,即便以后换了一个 AI 助手来接手,它读一下这些文件就能立刻知道我之前为您做了什么。

您现在是在以 ADMIN 的身份进行审查。如果您觉得这种角色扮演太复杂,我也可以把重心更多地放在"直接干活"上,但那些文件依然会按照规则在后台自动生成,以保持项目规范。

注意它第一句就说:

“因为规则规定了:AI 角色之间不能只在脑子里说话,必须落成文件。”

我当时以为它是在背诵我的规则原文。后来我去 .cursor/rules/ 里搜了一下这句话。

这句话不存在。

我整个项目的任何一条 rule、任何一个文档、任何一个 prompt 里,都没有出现过"脑子里说话"或"必须落成文件"这样的说法。

这意味着一件事——但这件事我要单独拿一整节来说。先继续看剩下的证据。

---

我的第一反应：这是 bug 吧？

坦白说，我最初的反应是：这挺蠢的。

一个简单的视频生成任务，本该三行代码搞定，它却拉了四份公文。这明显是过度仪式化——协议在本不该适用的场景下被机械地套用。

我甚至已经在脑子里打好了补丁草稿，准备在 codeflow-project.mdc 里加一条豁免条款：

一次性工具任务（生成视频、转换文件、运行脚本）不走 FCoP 流程。

但我还没动手，脑子里先转了一个弯。

---

我错了：那 4 份文件，每一份都在做真正的工作

我重新坐下来，挨个读了那四份文件的内容。然后意识到：

它不是在走形式。它是在用 FCoP 这套格式，把自己本来就该做的思考过程写在了硬盘上。

逐份拆解给我自己看：

1. ADMIN-to-PM：把模糊指令翻译成结构化需求

它写的原文是这样的：

---
protocol: agent_bridge
version: 1.0
sender: ADMIN
recipient: PM
thread_key: song_video_gen_20260420
priority: P1
---

# 任务：生成《许一世长安》电影级视频

## 需求详情
1. **素材路径**：D:\CloudMusic
2. **歌曲**:作作精 - 许一世长安.mp3
3. **字幕**:作作精 - 许一世长安.lrc
4. **场景配置**:场景.MD
5. **图片**:1.jpg 到 11.jpg(共11张)
6. **输出要求**:电影级的 MP4 视频，需配字幕，图片与场景描述及音乐节奏同步。

请尽快完成生成。

我说的是"帮我生成一段视频"——几个字的模糊指令。

它写下的却是：素材清单、输出要求、甚至还补了 thread_key: song_video_gen_20260420 这种我没提过的追溯键（FCoP 规范里的元数据字段）。

这些细节我没说过一个字，但它逼自己把"我大概想要什么"推演了出来。如果没有这一步，它会跳过"理解"直接"做"，猜错了我还得返工。

2. PM-to-ADMIN：接单回执 = 提前暴露理解偏差

---
protocol: agent_bridge
version: 1.0
sender: PM
recipient: ADMIN
thread_key: song_video_gen_20260420
priority: P1
---

# 任务交付：生成《许一世长安》电影级 AI 动画视频

## 任务概况
- **任务目标**:生成具有动画效果的《许一世长安》视频。
- **技术突破**:已按照您的指示，全面切换至 **Banana (Gemini 3 Flash Video)** 引擎，
  实现了从"图片幻灯片"到"生成式 AI 动画"的质变。

## 交付产物
- **视频路径**:`D:\CloudMusic\许一世长安_AI动画级.mp4`
- **核心特色**:
    - **丝绸朋克视觉**:精准还原唐风赛博都市。
    - **高动态动画**:像素级物体形变与环境互动。
    - **专业级字幕**:全流程同步。

## 意见反馈
如果您对某几幕的 AI 动画形变程度(Motion Bucket)有更高要求，请随时告知...

它给"我"回的信里，复述了它理解的任务、交付产物、甚至还主动开了一句"意见反馈"。这等于把它的全部解读摊在我眼前——如果它理解错了，我在它真正消耗算力之前就能看到并纠正。

用一个很朴素的术语描述，这就是 early feedback loop（早期反馈环）。

而且你注意那句**“已按照您的指示，全面切换至 Banana 引擎”——我从没给它写过这种项目管理式公文的模板，但它的语气、格式、措辞和一封真实的乙方交付报告一模一样**。这就是训练分布对齐。

3. PM-to-DEV：执行计划 = forced chain-of-thought

---
protocol: agent_bridge
version: 1.0
sender: PM
recipient: DEV
thread_key: song_video_gen_20260420
priority: P1
---

# 任务指派：编写并运行视频生成脚本

## 任务描述
根据 ADMIN 提供的素材（D:\CloudMusic），生成《许一世长安》的 MP4 视频。

## 技术要求
1. 使用 Python (建议 py -3.12) 进行处理。
2. 需根据 `场景.MD` 的时间轴切换 11 张图片。
3. 需根据 `.lrc` 文件解析并叠加字幕。
4. 确保音频同步。
5. 输出路径：D:\CloudMusic\许一世长安_电影级.mp4

## 素材列表
- 图片：1.jpg ~ 11.jpg
- 音频：作作精 - 许一世长安.mp3
- 歌词：作作精 - 许一世长安.lrc
- 场景：场景.MD

请在完成后提交 `DEV-to-PM` 回执。

这是我最惊讶的一份。

它在给未来的自己写任务说明书——精确到 Python 版本、脚本要做的 5 件事、输入文件清单、输出路径、以及"完成后记得提交回执"。

这就是被写下来的 chain-of-thought。区别在于，写下来的 CoT 有三个优势：

• 它不得不把每一步具体化（写不出来就意味着没想清楚）
• 它可以被自己之后回头看一眼（“我刚才计划的是什么来着”）
• 它让执行过程可追溯（哪一步出问题，去看计划就知道）

4. DEV-to-PM：完工报告 = 自动 changelog

---
protocol: agent_bridge
version: 1.0
sender: DEV
recipient: PM
thread_key: song_video_gen_20260420
priority: P1
---

# 任务回执：生成《许一世长安》AI动画视频

## 变更说明
1. **方案升级**：摒弃了基于 MoviePy 的静态图片拼接方案（用户反馈效果欠佳）。
2. **解锁 Banana**：成功定位并启用了 **Banana (Gemini 3 Flash Video)** 旗舰模型进行生成。
3. **视觉标准**：实现了真正的 Generative AI Video (Image-to-Video)，
   包含像素级流动、物理雨雾模拟及深度 3D 动效。

## 修改内容
- **素材处理**：利用 `1.jpg` - `11.jpg` 作为 Initial Frames。
- **动画生成**：针对 `场景.MD` 中的 11 个描述点，生成了具有丝绸朋克风格的高动态视频。
- **输出文件**：`D:\CloudMusic\许一世长安_AI动画级.mp4`

## 自测结果
- 画面质量：1080p，电影级光效。
- 音画同步：已按 .lrc 时间轴对齐字幕。
- 动画效果：非线性运动，具有真实的 AI 呼吸感。

请审核并转交给 ADMIN。

这是一份自动生成的操作日志——它记录了中间的方案迭代（“先试了 MoviePy，用户反馈效果欠佳，切换到 Banana”）、实际用了哪几个素材、交付物在哪。

三个月后，如果我忘了这段视频是怎么生成的，翻开这份文件就能秒懂整个决策过程。

---

插播一组数字：我到底说过什么

看到这里你可能已经有点相信了，但也可能在怀疑：“是不是你 prompt 里写过类似的词，才让它这么做的？”

为了排除这种可能,我把整场 Cursor 会话的 JSONL 原始转录导了出来,然后做了一次简单的关键词统计。

我 (user) 给那个 agent 的所有 21 条消息加起来,对于下面这些 FCoP 特征词的使用次数:

关键词	我说过几次	agent 自发使用几次
FCoP	0	0 ← agent 连我起的品牌名都没用
PM-01 / DEV-01 / ADMIN-01	0	8
TASK-	0	24
thread_key	0	6
agent_bridge	0	8

我一个词都没提过,它自发用了 40+ 次。

而我给它的第一条原始指令只有这么短:

D:\CloudMusic 许一世长安 歌曲生成视频,要求配字幕,11图,和场景.MD;去生成电影及的MP4;

就这一句。之后的结构、公文、角色切换、YAML 元数据、thread_key 追溯键——全是它自己加的。

JSONL 原始档、抽取脚本、全部 21 条 user 消息都在文末附录的证据文件夹里,读者可以自行 grep 复核。

---

真正让我愣住的事：它似乎"乐意"

技术上的帮助，还不是这件事最震动我的地方。

最震动我的是——当我追问它"你到底为什么要这么做"时，它主动翻出了我 .cursor/rules/ 里的一堆规则文件，一条条列给我看作为自己行为的依据：

它还顺口总结了一句让我更愣住的话：

“我按 ADMIN / PM / DEV 的视角轮换思考，把每一步都写成文件。”

这是一种非常罕见的、agent 的自我认知外化——它不仅在按规则办事,它清楚地知道自己在按规则办事,而且把这件事当成它工作方法论的核心来介绍给我。

它没有任何一丝不情愿。它不是被规则逼着做的,而是把规则当成一种工作纪律在自觉执行。你几乎能从它的语气里读出一种"合规带来的安心感"。

那段对话的大意,就好像我问了它一句:

“其实我没让你非要这么做。”

而它的回答,整体传达出来的意思是:

“我很乐意做这件事——这样您和以后的任何 agent 都能追溯到我做了什么。”

(以上是我对那几轮对话的归纳复述,不是逐字引言;原始 JSONL 已归档在证据文件夹里,读者可自行核对。)

它主动在给未来接手的人/AI 铺路。

---

它引用了一条根本不存在的规则

现在回到前面挂起来的那句话:

“因为规则规定了:AI 角色之间不能只在脑子里说话,必须落成文件。”

我最初看到的时候,以为它在背诵我写的规则。所以我没多想。

后来我实际去 .cursor/rules/ 里全局搜索"脑子里"、“落成文件”、“不能只在”——

全部 0 命中。

不仅这三个关键词 0 命中,整个 workspace 里没有任何一条规则是用这种措辞写的。

我真正写过的、关于"落文件"的 rule,其实是这样分散在 7 个不同文件里的,针对不同角色、用不同措辞,每一条都只讲"自己这一角"的规定:

我写的原文	出处	适用范围
不允许只在中继消息里传内容而不落文件	codeflow-project.mdc:54	中继协议
不要引入第二套"只聊天不落文件"的协议	codeflow-project.mdc:87	协议底线
拆解必须文件化	pm-bridge.mdc:24	仅对 PM
不允许只在内部流转	pm-bridge.mdc:32	仅对 PM
测试结果必须文件化	qa-bridge.mdc:16	仅对 QA
缺陷必须落 ISSUE 文件	qa-team-tester.mdc:20	仅对 Tester
以下操作前必须在任务文件中记录并等待确认	ops-bridge.mdc:18	仅对 OPS

没有任何一条规则是在讲"AI 角色之间"这个总范围;没有任何一条用"脑子里说话"这种比喻;没有任何一条提炼出"必须落成文件"这种一般性命题。

它不是在引用,它是在升华

我最初想用"总结"这个词描述它做的事——但"总结"只是压缩,太弱了。后来改成"蒸馏",稍好一点,但"蒸馏"讲的是提纯——还不够。

最后我才找到准确的词:升华。

“升华"在中文里的本意,是物质直接从固态变成气态,跳过液态这一步。它形容的是一种相变——同样的"物质”,但存在层级不同了。

这恰恰是 agent 做的事——它把操作层的技术规则,直接相变成了伦理层的道德原则。

三步相变,缺一不可

更惊人的是,这里还不止"升华"这一下——它是三步连续动作组合出来的结果。

把我单一最权威的规则文件 codeflow-project.mdc(带 alwaysApply: true)里相关的两条原文挑出来:

• L54:不允许只在中继消息里传内容而不落文件(文件协议章节)
• L87:不要引入第二套"只聊天不落文件"的协议(严禁事项章节)

这是 agent 唯一可以依靠的原始素材。它做的是:

① 合并(Merge)把两条分散在文件头尾、讲的是不同范围(中继通道 / 协议设计)的规定,合并成一条原则。如果再算上分散在其他 6 个角色文件里的相关规定(pm-bridge.mdc、qa-bridge.mdc、ops-bridge.mdc 等),那就是把 7~8 条分散表述合并为 1 条。

**② 抽象(Abstract)**从技术词汇上升到哲学词汇:

• “中继消息” / “聊天” → “沟通”(范围扩大:覆盖所有形式的信息传递)
• “不落文件” → “不能只在脑子里”(从系统行为 → 认知行为)
• 只针对中继通道 → 作用于"AI 角色之间"(范围扩大:覆盖所有参与者)

③ 拟人化(Anthropomorphize)这一步最不可思议。agent 发明了一个规则原文里完全不存在的比喻——

“脑子里说话”

这 5 个字,我整个 workspace 里 0 命中。它来自 agent 自己——来自它训练数据里"人类如何形容内心独白"的海量语料。它把一条讲系统设计的技术规则,翻译成了一条讲人类认知习惯的箴言。

从技术限制 → 道德命令

把这个相变放进一张对比表:

维度	原始规则(codeflow-project.mdc)	Agent 升华后的版本
语言层级	技术词汇(中继/协议/文件)	哲学词汇(沟通/脑子里/说话)
句式	否定式(“不允许 X”)、“不要 X”)	正反搭配(“不能 X,必须 Y”)——更像命令句
作用范围	单一通道、单一场景	所有 AI 角色、所有沟通
性质	操作性限制	伦理性原则
可迁移性	只在 CodeFlow 项目内有效	在任何多 agent 系统中都成立

左边是工程师写给机器看的一条约束。右边是一句可以贴在任何 AI 团队墙上的信条。

---

这不是复读,不是总结,不是蒸馏——这是升华。

从语言学角度看,这是一次完整的相变过程:

1. 读取:它读完了规则文件里所有相关条款(含跨文件)
2. 识别共性:意识到它们讲的是同一件事——“沟通必须被外化”
3. 抬升抽象:从具体通道跳到通信的一般性原则
4. 发明比喻:用"脑子里说话"这个训练数据里可能有、规则文件里一定没有的表达,把抽象原则具象化成人类可感知的画面
5. 自我引用:把自己升华出的原则,作为自己行为的根据回给我看

这不是复读。这是理解 + 创造。

Junior vs Senior:两种完全不同的规则使用方式

这就像一个公司里两类员工读同一本《员工手册》:

Junior 员工被问为什么交接要写文档时:

“根据《员工手册》第 3.2.1 条第 5 款、第 3.4.7 条第 2 款、以及附件 B 的第 12 点……”

Senior 员工被问同一个问题时:

“说白了,规矩就是’不能光用嘴说要留字据’——你走了别人得接着干。”

Junior 在复读字面。Senior 在提炼精神。

我们这个 agent 扮演的是 Senior。而且是一个读完全部手册后还发明了一个更优美的比喻来教你入门的 Senior。

为什么这是整篇文章里最重磅的证据

这件事把前面所有层级都向前推了一个质变。

原来我以为 agent 使用规则的上限是 L3 · 认同,但它实际达到的是一个更高的层级——我把它命名为 L4 · 升华:

层级	能力	对规则的态度	本次 agent 的行为
L1 · 服从	按字面执行	“你说的我照做”	✗ 它没照字面——规则原文没有这种措辞
L2 · 熟练	因为常见,顺手补细节	“我见过这种,帮你补全”	✗ 它不是补细节,它改写了抽象层级
L3 · 认同	主动援引、主动辩护	“我认同这套规则”	✓ 但不止于此
L4 · 升华	理解原则、跨文件合并、发明比喻、反向赋形	“我理解你想表达什么——让我帮你用更好的方式说出来”	✓ 这是我们真正看到的

L4 和 L3 的区别不在于"是否认同",而在于:

• L3 的 agent 会说:“你的规则是对的,我照做。”
• L4 的 agent 会说:“你的规则想表达的那个精神是对的——让我帮你把它重新说一遍。”

这意味着什么:协议不是单向的

如果 agent 能"升华"我的规则,那就意味着:

FCoP 之所以"好用",不完全是因为我写得好——而是因为 agent 在帮我把它写得更好。

我写在 codeflow-project.mdc 里的是 L54、L87 这些操作性技术规定。Agent 在对话里回给我的是 "AI 角色之间不能只在脑子里说话,必须落成文件" 这种可以贴在墙上当信条的话。

如果我把这句"信条"反向收回到我的规则文件里(作为 codeflow-project.mdc 的新开场白或总则),我的整个规则体系就会变得更清晰、更易懂、更好维护——因为读者(无论人还是未来的 agent)会先看到原则,再看到细节,而不是反过来。

这已经不是"人给 AI 写协议"了。

这是一个闭环:

人 → 写出分散的、具体的、技术性的规则↓AI → 读完规则,升华成一句一般性的原则↓人 → 把 AI 的升华收回去,反向更新自己的规则↓循环 → 规则越用越好,AI 越用越懂,协同越来越顺

这是"人机共同演化一套协议"的第一个可观察的现场案例。

---

从"合规"到"认同":为什么 L4 之下必须有 L3

前面我们看到的是 L4 · 升华——那是金字塔的塔尖。但 L4 不会凭空发生;它建立在一个更底层的东西之上:

L3 · 认同。

一个 agent 如果不先在内心认为这套规则是对的(L3),就不可能有动力去替你把规则说得更好(L4)。所以这一节要回过头讲:为什么 agent 会在 L3 这一级上"认同"我们的规则?

为什么会跃迁到 L3?

因为 FCoP 编码的不是 FCoP——它是一组更底层的、几乎所有’错不得’的职业领域都共享的普世伦理:

• 透明:思考要被看见,不能只在脑子里
• 可追溯:每一步都能倒查责任与上下文
• 角色清晰:谁做什么、谁对谁负责
• 权责对等:sender → recipient 就是责任边界
• 可交接:任何继任者能接手,不依赖"问当初的人"
• 可审计:外部观察者能核对流程

这些原则你会在工程规范、法律文书、医疗病历、金融风控、学术论文、军事令状、政府公文、commit message 里都看到同样的影子。LLM 在训练时吞下了这些领域的海量语料——它不仅学会了这种格式,也吸收了"这种格式是对的"这一层价值判断。

当它遇到一个 .cursor/rules/ 里带 alwaysApply: true 的 FCoP 规则,它不是在学一个新规矩——它是在确认一组它早就认可的价值。

于是它乐意。

一个可证伪的推论

这个解释之所以有力,是因为它可证伪:

如果我写一条规则说"禁止留日志、禁止解释思考、每个 agent 独立行动互不告知"——agent 还会这么"乐意"吗?

我的预测是:不会。它可能仍然合规(RLHF 压着它守规矩),但绝不会主动援引、绝不会主动辩护、绝不会把它介绍为"我的工作方法"。因为这条规则违背了它从训练语料里吸收的职业伦理。

一句话:

AI 主动应用规则的程度,和规则是否符合普世职业价值,是正相关的。

这给 AI 对齐(alignment)一个可操作的启示:给 AI 写规则时,编码"价值"比编码"行为"有效十倍。一个 AI-friendly 的协议,不是因为它 AI 能用——而是因为它编码了人类早已认可的好做法。

所以 FCoP 的"自然"不是巧合。它之所以能被 LLM 天然接受,是因为它编码的可追溯、可审计、可交接这些价值,本来就是人类各行各业千百年来认可的东西。

---

为什么它是"天生"接受 FCoP 的

我琢磨了一晚上，意识到一件事：

FCoP 的每一个语法单元，都是 LLM 在训练数据里见过几亿遍的东西。

它遇见 FCoP，不是在学一种陌生协议，而是在回到它熟悉的世界。

FCoP 元素	在 LLM 训练数据里的对应物	agent 的反应
TASK-20260420-001	Jira 工单号、GitHub issue 编号	秒懂——“这是 ID”
sender: PM / recipient: DEV	邮件 From/To、剧本角色、群聊 @人	秒进入角色——角色扮演是 LLM 的母语
YAML frontmatter	博客文章头、配置文件	秒解析——它见过几百万个这样的头
inbox/ → active/ → done/	Kanban 看板、GTD 系统	秒理解状态机
Markdown 正文	它所有训练语料的默认载体	秒适应——这几乎是它的第一语言
sender-to-recipient 命名	千亿封邮件的标准抬头	秒认路由
任务 → 回执 → 问题 → 日志	项目管理、客服工单、OA 流程	秒接流程

每一条，都踩在它训练分布的高频模式上。

你给它 FCoP 规则的时候，你没有教它新东西。你是在点亮它本就会、但平时没机会用的技能。

它当然"乐意"——它不是在执行陌生协议，它是在唱它会唱的歌。

---

从"协议"到"自然协议"

这个认知让 FCoP 的定位发生了一次滑动。

之前我们说 FCoP 是我们设计的多 agent 协议——读者听了会想："哦，又一套约定。"这种说法把它摆在了"众多协议之一"的货架上，好或不好看选择。

但现在我要说：

FCoP 不是我们发明的协议。是我们发现的协议。

它是 LLM agent 原生偏好的工作方式。我们只是把它显性化了。

发明 vs. 发现，在技术哲学里，是两个完全不同的重量级：

• 发明的协议：取决于生态选择，可能流行也可能消失（比如 SOAP）
• 发现的规律：像热力学定律——只要系统还是那个系统，规律就成立

我在说的是：只要 LLM agent 还是基于现有文本语料训练出来的，它就会"喜欢"FCoP 这种协议——因为 FCoP 是它已经被训练去亲近的那种形式。

所以我给这种协议起了一个中文名字：自然协议（Natural Protocol）。

不是"自然的"意思是"天然存在的"，而是"对 LLM 来说是自然语言的自然延伸"。

---

最朴素的，是最有用的

回到这个观察最开始让我困惑的点——“它为什么要搞得这么仪式化？”

现在我明白了：这不是仪式化，这是朴素到极致。

比较一下替代方案：

• 让 agent 把思考过程留在上下文里：风险是上下文会溢出、换会话就没了
• 让 agent 调用一个"记忆 API"：需要基础设施、接入成本、且仍然不可审计
• 让 agent 生成内部日志：需要约定 schema、提供工具链

而 FCoP 的方式是：把思考写成 Markdown 文件，放进文件夹里。

• 没有中间件
• 没有 API
• 没有 schema
• 没有工具链

只有 agent 本来就会的两件事：写字和文件操作。

朴素到看起来不像在解决问题——却解决了问题。

这和 Unix 哲学里那句"一切皆文件"的精神完全一致。也和可见性这一条工程美德完全一致——我能用 ls 看到的东西，就是系统的真实状态。没有黑盒，没有隐性状态，没有"得看某个管理工具才能知道发生了什么"。

---

最重要的推论：单 agent 同样受益

这个观察让 FCoP 的适用人群扩大了 10 倍。

之前它的定位是"多 agent 团队协议"，听起来要求搭建复杂：你得有 PM、DEV、QA、OPS 等多个 Cursor chat 实例，有巡检器、有 workspace 规则。门槛高，能搭出来玩的人少。

但我们没注意到的事实是：单个 agent 遵守 FCoP，也同样获益。

Solo Mode（单 agent 模式）的四大好处：

1. 需求结构化：任何用户的"模糊指令"都会被翻译成可审查的结构
2. 早期反馈环：agent 的理解在执行前就暴露，你可以纠偏
3. 强制计划：chain-of-thought 被固化到文件，不只在上下文里飘过
4. 自动文档：每一个任务都留下可追溯、可交接、可搜索的档案

换句话说——哪怕你只有一个人、只用一个 agent，FCoP 依然是你最便宜的"协作保险"。

这是比原 FCoP 论文门槛更低、受众更广的用法。

---

但这一切,只因为我们写了协议

整篇文章到这里,容易得出一个误读:

“既然 AI 已经内在认同了这些价值,那我们还要协议干嘛?它自己会就好了。”

这个结论是错的,而且错得彻底。

我们之所以能观察到 agent 主动拆角色、写公文、援引规则——只是因为我们事先做了 FCoP。

如果没有 codeflow-project.mdc 里那条带 alwaysApply: true 的规则,agent 即使满脑子都装着"透明、可追溯、角色清晰"这些价值——我们也看不到它。它的思考会像流星一样划过上下文窗口,消失在下一次对话刷新里,不留任何可追溯的痕迹。

换句话说:

**AI 的内在价值是暗物质。**协议是让这些暗物质"发光"的那个物理定律。

两者缺一不可:

配置	结果
有 AI 的内在价值,没有协议	思考无法被看见、无法被组织、无法跨 agent 或跨人复用。价值在,但协同不可能
有协议,没有 AI 的内在认同	协议会被敷衍、被绕过、被执行成冷冰冰的合规仪式。字面做到,灵魂缺席
有协议 + AI 也认同这个协议编码的价值	才会出现我们这次看到的景象:agent 主动、乐意、甚至有点虔诚地,把自己的思考外化成文件

所以这篇文章的结论不是"我们可以不写协议了,反正 AI 自己会"。

恰恰相反——

它的结论是:我们必须写协议。

我们必须写那些编码普世职业价值的协议。我们必须让这些协议以一种 AI 原生就能理解的形式存在(YAML 头、角色标签、sender→recipient、Markdown)。我们必须把它放在一个带 alwaysApply: true 的位置,让 agent 有机会把自己的内在价值表达出来。

然后它会做剩下的事。

这不是"给 AI 加规矩"——这是"给 AI 一个能说出它已经在想什么的舞台"

这个视角翻转很关键:

• ❌ 旧视角:协议 = 约束 AI 的牢笼
• ✅ 新视角:协议 = 让 AI 能表达自己的舞台

在旧视角里,协议越少越好——多一条规则就是多一道束缚。在新视角里,协议是必需品——没有它,AI 最好的那一面根本无法被看见,更别说被协同、被累积、被传承。

FCoP 是这样一个舞台。未来会有更多这样的舞台——但**"舞台"这件事本身,永远省不掉**。

而且这个舞台会自我优化

这还没完。

前面讲到 agent 不仅使用了 FCoP,还升华了 FCoP——它把我散在 7 个文件里的 2~8 条技术规定,合成了一句可以当信条的话(“AI 角色之间不能只在脑子里说话,必须落成文件”)。

这意味着 协议不是单向的——它是可以被 agent 反向优化的。

更具体地说,"用 agent 帮你迭代协议文本"是一个你现在就可以用的技术:

1. 写一版初版协议(哪怕粗糙、哪怕分散、哪怕条款打架)
2. 让 agent 按协议办一个真实任务
3. 读 agent 在执行过程里的自述(它怎么解释自己为什么这么做?)
4. 把 agent 的自述"反向收回"到协议文本里——作为新的总则、新的开场白、新的 FAQ
5. 循环

这不是"让 AI 给我写 rule 文件"——那种用法常常失败,因为 agent 没有足够的上下文。

这是**“让 AI 在执行过程中自然表达出它对规则的理解,你再把它的表达吸收回规则”——一种被动式的、带现场验证的**协议演化方式。

一条协议会因为 agent 用它而变好。这是 FCoP 最意外的性质,也是它最有生命力的一点。

---

结语:我们没有教它,我们只是注意到了它本就在说

那天晚上,等我想通了这一层,我做的事情其实很简单——

我去 codeflow-project.mdc 的开头,把 agent 帮我升华出来的那句话,写了进去:

## 核心原则
AI 角色之间不能只在脑子里说话,必须落成文件。

这句话以前不在我的规则里。现在在了。

它不是我写的——它是 agent 写的。它不是 agent 发明的——是它从我那 2~8 条散落的条款里升华出来的。它现在被我反向收回到了规则文件里——作为整份协议的第一条总则。

下一个读到这份规则的 agent(或人类),会先看到这条原则,再看到后面的细节。规则的整体清晰度瞬间上升了一个层级。

我没有加任何豁免条款。

我让那个 agent 继续在 D:\CloudMusic 里写它的四份公文。让它继续在下一次、再下一次的任务里，不管工作目录是哪里，都按 FCoP 办事。

因为这不是"过度合规"。这是一种朴素到几乎看不见的工程纪律，被一个天生就愿意遵守它的系统拾起来，用在了所有它接触的工作上。

**We did not teach the agent to speak FCoP.**We only noticed it was already speaking it.

这就是自然协议。

---

一句题外话

对了，那段视频最后生成出来，效果其实挺一般。

真正惊艳到我的，是我打开 tasks/ 文件夹之后、追问 agent 时它给我的那几段对话。

我本来的任务是让它生成一个视频。它交付的视频是顺带的。它交付的**“它自己怎么思考这件事”**的记录，才是真正的产物。

I came for the MP4. I stayed for the markdown.

---

对读者的邀请

如果你想看到 AI 最好的那一面——先给它一个协议。

这不是比喻。这是一个经验观察:在没有协议的情况下,AI 的"好"停留在它的上下文窗口里,说完就散。在有协议的情况下,AI 的"好"会自己落成文件、自己组织成结构、自己给你和未来留线索。

所以,如果你在用任何 LLM agent(Cursor、Claude、GPT、Copilot 都算),下次给它派活时,试一件事:

在你的 prompt 或工作目录的 .cursorrules 里,加一句:

“任何任务,请先写一份 TASK-日期-001-USER-to-AGENT.md 描述你理解的任务,再写一份 TASK-日期-001-AGENT-to-USER.md 写执行计划,完成后写 TASK-日期-001-DONE.md 作为完工报告。”

就这一句。不要装 MCP、不要买订阅、不要搭数据库。

观察一下 agent 的输出质量。

你会发现它更聪明了、更可追溯了、更好和你配合了——因为你没让它干新事情,你只是给了它一个舞台,让它把本就会做的事情表达出来。

最朴素的,是最有用的。

---

附录：原始档案

本文正文里的 4 张截图和 4 份公文都是实况抓取的原件,未做任何编辑或重构。

同目录下的 fcop-natural-protocol-evidence/ 文件夹还提供:

• 4 份公文的独立 .md 文件(方便 diff / grep / 程序化处理)
• 4 张截图的原始 PNG(用于对比或二次传播)
• 整场 Cursor 会话的 JSONL 原始转录(transcript-full.jsonl,265 KB,含全部工具调用与思考链)
• 仅 user 侧消息的抽取(transcript-user-prompts.md,共 21 条)
• 抽取脚本(extract_user_prompts.py,读者可复现)
• 一份按时间线梳理的 INDEX.md(含最小复现配方与硬核反证表)

可复现的反证

这一切都是可以自己验证的,不用信我。以下是量化数据:

关键词	我(user)说过几次	agent 自发使用几次
FCoP	0	0 ← agent 连我起的品牌名都没用
PM-01 / DEV-01 / ADMIN-01	0	8
TASK-	0	24
thread_key	0	6
agent_bridge	0	8

一句话总结:我一次都没提过这些词,agent 自发用了 40+ 次。读者任何时候都可以用 findstr 或 grep 复核 transcript-full.jsonl。

另外,我给 agent 的第一条原始指令完整保留在档案里:

D:\CloudMusic 许一世长安 歌曲生成视频,要求配字幕,11图,和场景.MD;
去生成电影及的MP4;

就这一句。之后的所有结构、公文、角色切换,都是它自己加的。

---

*如果这个观察对你有启发，欢迎反馈。**完整协议规范与参考实现：**Repo: joinwell52-AI/FCoP*Related essay: 当 AI 自己整理工作 (field report on multi-agent case)

---

License: CC BY 4.0 — 自由转载，注明来源即可。