即刻App年轻人的同好社区
下载
置顶Yibie 的自我策展
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
我整理之前发过的帖子，这些是值得推荐一看的。也顺道向你暴露我的世界观、性格、兴趣和观点，有机会的话交个朋友😊
✨ AI 与新世界
得到 Prompt 系列（共 18 个） ⭐️已被“提示词图书馆收录”
m.okjike.com
Promopt: 文章精炼大师
web.okjike.com
Promopt: 概念卡片制作专家
web.okjike.com
Promopt: PPT 大纲制作助手 ⭐获得即刻精选推荐
web.okjike.com
Promopt: Kiweb. 文章精华浓缩专家
web.okjike.com
开发 12 Weeks LifeRPG 背后的过程与思考
web.okjike.com
用 AI 帮忙总结笔记（测试了 ChatGPT、Gemini、Kiweb.、豆包）
web.okjike.com
微软 CTO Kevin Scott 接受 every 访谈
web.okjike.com
吴恩达总结 AI 工程师制作 Promopt 的经验
web.okjike.com
OpenAI 2024 年春季发布会源文件， 包括演讲稿和演示用代码
web.okjike.com
视频内容识别是 Gemini Pro 1.5 的杀手锏
web.okjike.com
Perplexity 的官方 Promopt
web.okjike.com
大模型公司对 Token 的计算方法都不一样
web.okjike.com
AI 与创作者经济
web.okjike.com
------------------------------------
🤔我对这个世界有点看法
every 长文: AI 将冲击广告业, 后果很严重
web.okjike.com
Vision Pro 之我见
web.okjike.com
社会生活的趋同让人恐惧
web.okjike.com
「探索式」笔记法 ⭐获得即刻精选推荐
web.okjike.com
子弹日记法
web.okjike.com
商业价值的 3 个重要特征
web.okjike.com
Arc 这家公司的特点
web.okjike.com
新产品形态: Jina AI 将 URL 变为 API
web.okjike.com
------------------------------------
📒囤了一些清单
值得推荐的豆瓣小组
web.okjike.com
包豪斯设计的精华链接
web.okjike.com
Design Engineer 的 Twitter List
web.okjike.com
------------------------------------
📖️那些值得推荐的好书
读完斯多葛主义代表人物塞涅卡的书信集 <短暂的生命>
web.okjike.com
程序员超强大脑笔记
web.okjike.com
读完<巨人的工具>
web.okjike.com
读完<为什么伟大不能被计划>
web.okjike.com
精要主义读书笔记
web.okjike.com
读《了不起的盖茨比》
web.okjike.com
------------------------------------
💭️脑海里闪过的一句话
天才税
web.okjike.com
高度抽象的现代生活损害人类天生的类比能力
web.okjike.com
你能列出充分反映时代精神的 3 家公司吗？
web.okjike.com
解决拖延症的办法是找出之前最想完成但一直没做的事
web.okjike.com
美 = 深刻的简洁
web.okjike.com
尊重常识 = 不犯基本错误
web.okjike.com
与其花 1 小时如昙花一现, 不如花 10 倍时间震惊四座
web.okjike.com
这个世界有种人，以好人为食。
web.okjike.com
最难沟通的，是被灌输了标准答案的人
web.okjike.com
拖延 = 甩锅给未来的自己
web.okjike.com
折腾的定义
web.okjike.com
------------------------------------
🛠喜欢折腾工具
开启 Mac 系统自带白噪音音乐的方法
web.okjike.com
20-20-20 护眼原则
web.okjike.com
用哔哩哔哩替代网易云音乐
web.okjike.com
中国著名羽毛球运动员郑思维学习英语的工具和方法
web.okjike.com
------------------------------------
📁未归类的答案
「参考答案」的策展原则
web.okjike.com
50 919
超越模型：LLM 调用方式的系统性思考
1. 两个背景：Harness Problem 与蜂群机制
要理解 LLM 调用方式的系统性问题，我们需要先回顾两个独立但相关的技术探索。
1.1 Harness Problem：Can Bölük 的发现
2026 年 2 月，工程师 Can Bölük 发布了一篇名为"The Harness Problem"的博客文章，揭示了一个令人震惊的事实：仅仅通过优化 LLM 的调用格式（edit tool），就能让 15 个不同 LLM 的编码能力提升 10 倍。
具体数据：
- Grok Code Fast 1：成功率从 6.7% 提升到 68.3%（10 倍提升）
- MiniMax：成功率翻倍
- Gemini：+8% 的提升
成本：零训练计算，仅约 $300 的 benchmark 费用
核心问题：现有的编辑工具（如 Codex 的 apply_patch、Claude Code 的 str_replace）都要求模型"说出"特定格式的内容——要么是特定的 diff 格式，要么是完美的字符复现。这导致模型"理解"了要做什么，但"说不出来"，就像"责怪飞行员，其实是起落架的问题"。
解决方案：Can 提出了 Hashline 格式，给每行代码添加 2-3 字符的哈希标记（如 22:f1|return "world";），让模型通过引用哈希来编辑，而不是复现内容。
1.2 蜂群机制：多 Agent 协作的系统性框架
与此同时，在构建多 Agent 系统（Agent Swarm）的实践中，开发者们发现了另一组问题：单个 LLM 的能力可以通过提示工程优化，但当多个 Agent 协作时，系统会面临熵增的挑战。
熵增的表现：
行为发散：多个 Agent 走向不同方向
信息冗余：重复或冲突的信息传递
策略漂移：随着时间推移，方法不断变化
角色混乱：责任边界不清晰
系统性解决方案：通过三文件结构来约束和协调：
SKILL.md：定义每个 Agent 的能力边界
ROLE.md：明确角色职责（Planner/Critic/Doer）
PROTOCOL.md：规定协作协议（何时广播、何时私聊、何时交接）
多 Agent 系统不是简单的能力叠加，而是需要收敛系统来对抗熵增——包括投票机制、总结提炼、回滚快照、A/B 测试等。
2. 共同点：都关注"调用方式"
乍一看，Harness Problem 关注的是单个 LLM 的调用格式，而蜂群机制关注的是多个 LLM 的协作协议。但深入分析会发现，它们指向同一个被忽视的维度：LLM 的调用方式。
维度 Harness Problem 蜂群机制
关注点 单个 LLM 的调用格式 多个 LLM 的协作协议
核心问题 模型懂但"说不出" 多 Agent 熵增失控
解决方案 Hashline 格式优化 三文件结构（SKILL/ROLE/PROTOCOL）
单体调用方式决定能力上限 群体协作协议决定系统智能
无论是单体的调用格式，还是群体的协作协议，它们都属于"调用方式"这个更大的范畴——即LLM 如何接收输入、处理信息、输出结果、与其他 Agent 交互。
这引出了一个被行业长期忽视的事实：LLM 的能力不仅取决于模型本身（Layer 1），更取决于我们如何调用它（Layer 2 和 Layer 3）。
3. 引申：LLM 系统的三个层次
基于上述两个背景，我们可以构建一个系统性的框架，将 LLM 系统分为三个层次：
┌────────────────────────
│ Layer 3: 蜂群协作层（Swarm Layer）
│ - PROTOCOL.md: Agent 间如何协作
│ - 收敛系统: 投票、总结、回滚、A/B 测试
├────────────────────────
│ Layer 2: 单体调用层（Harness Layer）
│ - SKILL.md: 工具能力定义
│ - 调用格式: Hashline、函数调用、ReAct
├────────────────────────
│ Layer 1: 模型能力层（Model Layer）
│ - 基座模型（GPT-4、Claude、Gemini）
│ - 上下文窗口、推理能力、知识储备
└────────────────────────
3.1 Layer 1：模型能力层（基础但边际效益递减）
这是最直观的一层。GPT-4 vs Claude vs Gemini，更大的模型、更长的上下文、更好的推理能力。
现状：行业的大部分注意力都集中在这里。OpenAI、Anthropic、Google 每年投入数十亿美元训练更大的模型。
问题：边际效益正在递减。GPT-4 到 GPT-5 可能只有 20-30% 的提升，但成本是数亿美元。而 Harness Problem 显示，优化 Layer 2 可以有 10 倍提升，成本仅约 $300。
Layer 1 是基础，但不是当前最大的杠杆点。
3.2 Layer 2：单体调用层（最大的杠杆点）
这是 Harness Problem 揭示的关键层次。它是模型理解与模型能表达其理解之间的接口。
现有工具的问题：
- apply_patch：要求模型会"说"特定格式，其他模型失败率 50%+
- str_replace：要求模型背诵整段代码（包括空格），容易失败
- function_calling：虽然更结构化，但仍需模型遵循特定 schema
模型通常理解该做什么，但无法通过现有工具格式表达它。Can Bölük 的比喻很贴切："你在责怪飞行员，其实是起落架的问题。"
优化方向：
让模型用引用（如 Hashline）而非复现
减少格式约束，增加验证机制
设计让模型能"说出"理解的接口
杠杆效应：Harness Problem 证明，优化 Layer 2 可以实现 10 倍提升，且零训练成本。
3.3 Layer 3：蜂群协作层（新的复杂度前沿）
这是多 Agent 系统（Swarm）面临的挑战。单个 Agent 的能力可以通过 Layer 2 优化，但当多个 Agent 协作时，系统会涌现新的复杂度。
核心问题：
- 何时"喊人"（handoff）？如何定义失败信号？
- 如何对抗熵增？如何收敛到一致？
- 如何编排任务？广播 vs 私聊 vs 直接调用？
系统性解决方案：
- SKILL.md：能力定义（能做什么）
- ROLE.md：身份定义（是谁，负责什么）
- PROTOCOL.md：协作定义（如何交互）
Layer 3 是目前最不成熟但潜力最大的领域。一个协调良好的 Agent Swarm 可以解决单个 Agent 无法解决的复杂问题，但一个协调不好的 Swarm 会因为熵增而失败。
4. 深度思考：三层之间的关系
4.1 Layer 2 放大 Layer 1
一个 GPT-4 配合优化的调用格式（Hashline），可以胜过 GPT-5 配合糟糕的调用格式（apply_patch 用于错误模型）。
这意味着：在投入数十亿美元训练更大的模型之前，我们应该先问：当前的调用格式是否让模型能充分表达其能力？
4.2 Layer 3 乘以 Layer 2
一个协调良好的 Swarm 配合优化的单体调用（Layer 2 + Layer 3），可以产生涌现智能，解决单个 Agent 无法解决的问题。
但这有前提：如果 Layer 2 有问题（模型无法表达），或者 Layer 3 有问题（协作协议混乱），Swarm 会失败。
4.3 优化的优先级
基于以上分析，构建 LLM 系统的优化优先级应该是：
先优化 Layer 2（调用格式）- 10 倍杠杆，低成本
再构建 Layer 3（协作协议）- 新 frontier，高潜力
最后考虑 Layer 1（更大模型）- 边际效益递减
5. 实践框架：如何应用三层模型
当你构建 LLM 系统时，问自己以下问题：
Layer 2 检查清单（单体调用）
[ ] 我的调用格式是否让模型能轻松表达其理解？
[ ] 我是否要求复现，而引用就足够了？（如 Hashline）
[ ] 我是否有自动验证机制（哈希、校验和）？
[ ] 错误消息是否可操作，能让模型学习调整？
Layer 3 检查清单（蜂群协作）
[ ] 我是否有明确的 ROLE 定义？（Planner/Critic/Doer）
[ ] Agent 间通信是否有 PROTOCOL？（广播/私聊/调用）
[ ] 何时定义"失败"并"喊人"（handoff）？
[ ] 我是否有收敛系统对抗熵增？（投票、总结、回滚）
[ ] 系统能否回滚失败的策略？
Layer 1 检查清单（模型能力）
[ ] 基座模型是否具备所需的推理能力？
[ ] 上下文窗口是否足够容纳任务？
[ ] 对于这个特定任务，不同模型是否会更好？
6. 未来方向：开放问题
基于三层模型，以下是一些值得探索的开放问题：
6.1 自适应协议（Adaptive Protocol）
PROTOCOL.md 能否基于任务绩效自我优化？Swarm 能否随时间学习更好的协调策略？
可能的方向，让 Critic Agent 专职评估 PROTOCOL 的有效性，并提出改进建议。
6.2 动态角色生成（Dynamic Role Generation）
不是固定角色（Planner/Critic/Doer），而是根据任务负载动态创建临时 Agent：
"为这个代码审查创建 SecurityReviewer-v1"
"为这个功能生成 TestGenerator-2024-02"
关键问题：如何定义临时角色的 SKILL、ROLE 和 PROTOCOL？
6.3 统一标准（Unified Standards）
我们能否拥有 Layer 2/3 的标准，类似于 API 标准？
- 标准调用格式（如 Hashline 或更好的方案）
- 标准角色定义（可复用的 ROLE.md 模板）
- 标准协议原语（广播、私聊、交接、投票）
如果行业标准化了调用方式，将释放出巨大的创新潜力——就像 HTTP 标准化释放了 Web 创新一样。
通过融合 Harness Problem 和蜂群机制两个视角，我们获得了一个系统性的框架：LLM 的能力不仅取决于模型本身（Layer 1），更取决于我们如何调用它（Layer 2）和协调它（Layer 3）。
Harness Problem 揭示了一个被忽视的事实：模型与执行之间的差距往往是接口问题，而非能力问题。
蜂群机制 揭示了另一个事实：个体能力与系统能力之间的差距是协调问题，而非简单叠加。
两者共同指向一个被行业长期低估的维度：调用方式（Invocation）。
在继续追逐更大的模型（Layer 1）之前，也许我们应该先问自己：
当前的调用格式是否让模型能充分表达？（Layer 2）
当前的协作协议是否让 Agent 能有效协调？（Layer 3）
正如 Can Bölük 所说："你责怪飞行员，其实是起落架的问题。"
参考：
Harness Problem：blog.can.ac
1. 两个背景：Harness Problem 与蜂群机制
要理解 LLM 调用方式的系统性问题，我们需要先回顾两个独立但相关的技术探索。
1.1 Harness Problem：Can Bölük 的发现
2026 年 2 月，工程师 Can Bölük 发布了一篇名为"The Harness Problem"的博客文章，揭示了一个令人震惊的事实：仅仅通过优化 LLM 的调用格式（edit tool），就能让 15 个不同 LLM 的编码能力提升 10 倍。
具体数据：
- Grok Code Fast 1：成功率从 6.7% 提升到 68.3%（10 倍提升）
- MiniMax：成功率翻倍
- Gemini：+8% 的提升
成本：零训练计算，仅约 $300 的 benchmark 费用
核心问题：现有的编辑工具（如 Codex 的 apply_patch、Claude Code 的 str_replace）都要求模型"说出"特定格式的内容——要么是特定的 diff 格式，要么是完美的字符复现。这导致模型"理解"了要做什么，但"说不出来"，就像"责怪飞行员，其实是起落架的问题"。
解决方案：Can 提出了 Hashline 格式，给每行代码添加 2-3 字符的哈希标记（如 22:f1|return "world";），让模型通过引用哈希来编辑，而不是复现内容。
1.2 蜂群机制：多 Agent 协作的系统性框架
与此同时，在构建多 Agent 系统（Agent Swarm）的实践中，开发者们发现了另一组问题：单个 LLM 的能力可以通过提示工程优化，但当多个 Agent 协作时，系统会面临熵增的挑战。
熵增的表现：
行为发散：多个 Agent 走向不同方向
信息冗余：重复或冲突的信息传递
策略漂移：随着时间推移，方法不断变化
角色混乱：责任边界不清晰
系统性解决方案：通过三文件结构来约束和协调：
SKILL.md：定义每个 Agent 的能力边界
ROLE.md：明确角色职责（Planner/Critic/Doer）
PROTOCOL.md：规定协作协议（何时广播、何时私聊、何时交接）
多 Agent 系统不是简单的能力叠加，而是需要收敛系统来对抗熵增——包括投票机制、总结提炼、回滚快照、A/B 测试等。
2. 共同点：都关注"调用方式"
乍一看，Harness Problem 关注的是单个 LLM 的调用格式，而蜂群机制关注的是多个 LLM 的协作协议。但深入分析会发现，它们指向同一个被忽视的维度：LLM 的调用方式。
维度 Harness Problem 蜂群机制
关注点 单个 LLM 的调用格式 多个 LLM 的协作协议
核心问题 模型懂但"说不出" 多 Agent 熵增失控
解决方案 Hashline 格式优化 三文件结构（SKILL/ROLE/PROTOCOL）
单体调用方式决定能力上限 群体协作协议决定系统智能
无论是单体的调用格式，还是群体的协作协议，它们都属于"调用方式"这个更大的范畴——即LLM 如何接收输入、处理信息、输出结果、与其他 Agent 交互。
这引出了一个被行业长期忽视的事实：LLM 的能力不仅取决于模型本身（Layer 1），更取决于我们如何调用它（Layer 2 和 Layer 3）。
3. 引申：LLM 系统的三个层次
基于上述两个背景，我们可以构建一个系统性的框架，将 LLM 系统分为三个层次：
┌────────────────────────
│ Layer 3: 蜂群协作层（Swarm Layer）
│ - PROTOCOL.md: Agent 间如何协作
│ - 收敛系统: 投票、总结、回滚、A/B 测试
├────────────────────────
│ Layer 2: 单体调用层（Harness Layer）
│ - SKILL.md: 工具能力定义
│ - 调用格式: Hashline、函数调用、ReAct
├────────────────────────
│ Layer 1: 模型能力层（Model Layer）
│ - 基座模型（GPT-4、Claude、Gemini）
│ - 上下文窗口、推理能力、知识储备
└────────────────────────
3.1 Layer 1：模型能力层（基础但边际效益递减）
这是最直观的一层。GPT-4 vs Claude vs Gemini，更大的模型、更长的上下文、更好的推理能力。
现状：行业的大部分注意力都集中在这里。OpenAI、Anthropic、Google 每年投入数十亿美元训练更大的模型。
问题：边际效益正在递减。GPT-4 到 GPT-5 可能只有 20-30% 的提升，但成本是数亿美元。而 Harness Problem 显示，优化 Layer 2 可以有 10 倍提升，成本仅约 $300。
Layer 1 是基础，但不是当前最大的杠杆点。
3.2 Layer 2：单体调用层（最大的杠杆点）
这是 Harness Problem 揭示的关键层次。它是模型理解与模型能表达其理解之间的接口。
现有工具的问题：
- apply_patch：要求模型会"说"特定格式，其他模型失败率 50%+
- str_replace：要求模型背诵整段代码（包括空格），容易失败
- function_calling：虽然更结构化，但仍需模型遵循特定 schema
模型通常理解该做什么，但无法通过现有工具格式表达它。Can Bölük 的比喻很贴切："你在责怪飞行员，其实是起落架的问题。"
优化方向：
让模型用引用（如 Hashline）而非复现
减少格式约束，增加验证机制
设计让模型能"说出"理解的接口
杠杆效应：Harness Problem 证明，优化 Layer 2 可以实现 10 倍提升，且零训练成本。
3.3 Layer 3：蜂群协作层（新的复杂度前沿）
这是多 Agent 系统（Swarm）面临的挑战。单个 Agent 的能力可以通过 Layer 2 优化，但当多个 Agent 协作时，系统会涌现新的复杂度。
核心问题：
- 何时"喊人"（handoff）？如何定义失败信号？
- 如何对抗熵增？如何收敛到一致？
- 如何编排任务？广播 vs 私聊 vs 直接调用？
系统性解决方案：
- SKILL.md：能力定义（能做什么）
- ROLE.md：身份定义（是谁，负责什么）
- PROTOCOL.md：协作定义（如何交互）
Layer 3 是目前最不成熟但潜力最大的领域。一个协调良好的 Agent Swarm 可以解决单个 Agent 无法解决的复杂问题，但一个协调不好的 Swarm 会因为熵增而失败。
4. 深度思考：三层之间的关系
4.1 Layer 2 放大 Layer 1
一个 GPT-4 配合优化的调用格式（Hashline），可以胜过 GPT-5 配合糟糕的调用格式（apply_patch 用于错误模型）。
这意味着：在投入数十亿美元训练更大的模型之前，我们应该先问：当前的调用格式是否让模型能充分表达其能力？
4.2 Layer 3 乘以 Layer 2
一个协调良好的 Swarm 配合优化的单体调用（Layer 2 + Layer 3），可以产生涌现智能，解决单个 Agent 无法解决的问题。
但这有前提：如果 Layer 2 有问题（模型无法表达），或者 Layer 3 有问题（协作协议混乱），Swarm 会失败。
4.3 优化的优先级
基于以上分析，构建 LLM 系统的优化优先级应该是：
先优化 Layer 2（调用格式）- 10 倍杠杆，低成本
再构建 Layer 3（协作协议）- 新 frontier，高潜力
最后考虑 Layer 1（更大模型）- 边际效益递减
5. 实践框架：如何应用三层模型
当你构建 LLM 系统时，问自己以下问题：
Layer 2 检查清单（单体调用）
[ ] 我的调用格式是否让模型能轻松表达其理解？
[ ] 我是否要求复现，而引用就足够了？（如 Hashline）
[ ] 我是否有自动验证机制（哈希、校验和）？
[ ] 错误消息是否可操作，能让模型学习调整？
Layer 3 检查清单（蜂群协作）
[ ] 我是否有明确的 ROLE 定义？（Planner/Critic/Doer）
[ ] Agent 间通信是否有 PROTOCOL？（广播/私聊/调用）
[ ] 何时定义"失败"并"喊人"（handoff）？
[ ] 我是否有收敛系统对抗熵增？（投票、总结、回滚）
[ ] 系统能否回滚失败的策略？
Layer 1 检查清单（模型能力）
[ ] 基座模型是否具备所需的推理能力？
[ ] 上下文窗口是否足够容纳任务？
[ ] 对于这个特定任务，不同模型是否会更好？
6. 未来方向：开放问题
基于三层模型，以下是一些值得探索的开放问题：
6.1 自适应协议（Adaptive Protocol）
PROTOCOL.md 能否基于任务绩效自我优化？Swarm 能否随时间学习更好的协调策略？
可能的方向，让 Critic Agent 专职评估 PROTOCOL 的有效性，并提出改进建议。
6.2 动态角色生成（Dynamic Role Generation）
不是固定角色（Planner/Critic/Doer），而是根据任务负载动态创建临时 Agent：
"为这个代码审查创建 SecurityReviewer-v1"
"为这个功能生成 TestGenerator-2024-02"
关键问题：如何定义临时角色的 SKILL、ROLE 和 PROTOCOL？
6.3 统一标准（Unified Standards）
我们能否拥有 Layer 2/3 的标准，类似于 API 标准？
- 标准调用格式（如 Hashline 或更好的方案）
- 标准角色定义（可复用的 ROLE.md 模板）
- 标准协议原语（广播、私聊、交接、投票）
如果行业标准化了调用方式，将释放出巨大的创新潜力——就像 HTTP 标准化释放了 Web 创新一样。
通过融合 Harness Problem 和蜂群机制两个视角，我们获得了一个系统性的框架：LLM 的能力不仅取决于模型本身（Layer 1），更取决于我们如何调用它（Layer 2）和协调它（Layer 3）。
Harness Problem 揭示了一个被忽视的事实：模型与执行之间的差距往往是接口问题，而非能力问题。
蜂群机制 揭示了另一个事实：个体能力与系统能力之间的差距是协调问题，而非简单叠加。
两者共同指向一个被行业长期低估的维度：调用方式（Invocation）。
在继续追逐更大的模型（Layer 1）之前，也许我们应该先问自己：
当前的调用格式是否让模型能充分表达？（Layer 2）
当前的协作协议是否让 Agent 能有效协调？（Layer 3）
正如 Can Bölük 所说："你责怪飞行员，其实是起落架的问题。"
参考：
Harness Problem：blog.can.ac
5 21
# 从公司管理到人生管理：一套文件系统哲学 📁
最近读到 Eli Mernit 的一个观点：公司应该被建模为文件系统。这让我思考了很久——如果公司可以，那人生呢？
---
## 为什么企业 AI 难以落地？ 🤔
Eli Mernit 指出了一个核心痛点：数据孤岛。
- 发票在 Quickbooks
- 邮件在 Outlook
- 提案在 Sharepoint
- 合同在 Netsuite
没有统一的命名空间，AI Agent 无法获得完整的上下文，自然无法做出好的决策。
---
## 解决方案：公司即文件系统 💡
Eli 的方案极具 Unix 哲学的美感：
把整个公司建模为一个统一的文件系统。
核心原则：
- 统一命名空间 - 所有数据映射到文件路径
- 文件即状态 - 公司状态 = 文件内容
- 权限即治理 - 组织架构 = Unix 权限
- 读写即操作 - Agent 通过读写文件工作
---
## 文件夹结构示例 📂
```
/law-firm/
├── /cases/
│ ├── /active/
│ └── /archive/
├── /billing/
├── /contracts/
└── /staff/
```
在这个模型中，公司的所有状态都体现在文件中。
Agent 不需要 API 集成，只需要读写文件的权限。
---
## 权限即治理结构 🔐
最精彩的部分：
> "治理结构就是 Unix 文件权限。"
- 初级律师：只能读写自己的案件
- 合伙人：可以访问所有案件
- CFO：财务数据完全访问
传统的企业治理需要复杂的审批流程，文件系统模型下，权限边界就是治理规则。
---
## 从公司到个人 🚀
Eli 说的是公司。
但我想：人生难道不应该也是一个文件系统吗？
我们的个人数据同样散落在各个孤岛：
- 健康数据 → Apple Health / Garmin
- 财务数据 → 银行 App / 支付宝
- 笔记想法 → Notion / Obsidian
- 日程安排 → Google Calendar
- 人际关系 → 微信 / 通讯录
每个 App 都是一个数据孤岛。
---
## 核心哲学：文件夹即人生原则 💭
> 你管理文件夹的原则，就是你为人处事的原则。
这不是比喻，而是字面意义上的映射。
结构即思维方式：
- 清晰的目录结构 = 有组织的思维
- 混乱的桌面 = 混乱的优先级
归档即取舍智慧：
- 定期整理 = 懂得放下过去
- 文件堆积 = 被困在过去
权限即边界意识：
- 公私分明 = 健康的边界感
版本控制即成长思维：
- 珍视修改历史 = 相信成长是渐进的
---
## 人生文件系统的愿景 🌟
想象一下这样的人生管理系统：
```
~/life/
├── /goals/ - 人生目标
├── /projects/ - 正在进行的项目
├── /knowledge/ - 学习和思考
├── /relationships/ - 人际关系
├── /health/ - 健康数据
├── /finance/ - 财务状况
└── /reflections/ - 反思和日记
```
所有数据在一个地方，统一命名，统一结构，统一访问。
---
## 当 AI 成为你的分身 🤖
当人生是统一的文件系统，Openclaw 可以：
- 读取你的完整上下文
- 理解你的模式和偏好
- 代表你做出决策
- 持续学习和适应
### 分身场景愿景
日程助手分身：
读取你的目标、项目、健康数据，生成真正符合你节奏的日程。
健康教练分身：
分析你的睡眠、运动记录，发现你自己不知道的模式。
职业顾问分身：
了解你的技能和经验，给出真正个性化的职业建议。
---
## 推荐工具思路 🛠️
如果你想开始构建自己的人生文件系统：
基础工具：
- Obsidian - 本地 Markdown 笔记
- Logseq - 大纲式笔记
- VS Code + Git - 代码编辑器管理人生
同步与访问：
- Syncthing - 点对点文件同步
- Nextcloud - 自托管云存储
AI 集成：
- Openclaw - 文件系统优先的 AI
- Claude Code - 可以直接操作文件的 AI
---
## 总结 📝
公司即文件系统
→ 人生即文件系统
→ AI 即分身
当你的 life 是一个统一的文件系统，
AI 拥有的不只是数据，
而是你的完整上下文。
它终于可以像代表公司一样代表你。
---
## 讨论 💬
如果你的人生是一个文件系统，
你的根目录会是什么样？
原文来自：
x.com
最近读到 Eli Mernit 的一个观点：公司应该被建模为文件系统。这让我思考了很久——如果公司可以，那人生呢？
---
## 为什么企业 AI 难以落地？ 🤔
Eli Mernit 指出了一个核心痛点：数据孤岛。
- 发票在 Quickbooks
- 邮件在 Outlook
- 提案在 Sharepoint
- 合同在 Netsuite
没有统一的命名空间，AI Agent 无法获得完整的上下文，自然无法做出好的决策。
---
## 解决方案：公司即文件系统 💡
Eli 的方案极具 Unix 哲学的美感：
把整个公司建模为一个统一的文件系统。
核心原则：
- 统一命名空间 - 所有数据映射到文件路径
- 文件即状态 - 公司状态 = 文件内容
- 权限即治理 - 组织架构 = Unix 权限
- 读写即操作 - Agent 通过读写文件工作
---
## 文件夹结构示例 📂
```
/law-firm/
├── /cases/
│ ├── /active/
│ └── /archive/
├── /billing/
├── /contracts/
└── /staff/
```
在这个模型中，公司的所有状态都体现在文件中。
Agent 不需要 API 集成，只需要读写文件的权限。
---
## 权限即治理结构 🔐
最精彩的部分：
> "治理结构就是 Unix 文件权限。"
- 初级律师：只能读写自己的案件
- 合伙人：可以访问所有案件
- CFO：财务数据完全访问
传统的企业治理需要复杂的审批流程，文件系统模型下，权限边界就是治理规则。
---
## 从公司到个人 🚀
Eli 说的是公司。
但我想：人生难道不应该也是一个文件系统吗？
我们的个人数据同样散落在各个孤岛：
- 健康数据 → Apple Health / Garmin
- 财务数据 → 银行 App / 支付宝
- 笔记想法 → Notion / Obsidian
- 日程安排 → Google Calendar
- 人际关系 → 微信 / 通讯录
每个 App 都是一个数据孤岛。
---
## 核心哲学：文件夹即人生原则 💭
> 你管理文件夹的原则，就是你为人处事的原则。
这不是比喻，而是字面意义上的映射。
结构即思维方式：
- 清晰的目录结构 = 有组织的思维
- 混乱的桌面 = 混乱的优先级
归档即取舍智慧：
- 定期整理 = 懂得放下过去
- 文件堆积 = 被困在过去
权限即边界意识：
- 公私分明 = 健康的边界感
版本控制即成长思维：
- 珍视修改历史 = 相信成长是渐进的
---
## 人生文件系统的愿景 🌟
想象一下这样的人生管理系统：
```
~/life/
├── /goals/ - 人生目标
├── /projects/ - 正在进行的项目
├── /knowledge/ - 学习和思考
├── /relationships/ - 人际关系
├── /health/ - 健康数据
├── /finance/ - 财务状况
└── /reflections/ - 反思和日记
```
所有数据在一个地方，统一命名，统一结构，统一访问。
---
## 当 AI 成为你的分身 🤖
当人生是统一的文件系统，Openclaw 可以：
- 读取你的完整上下文
- 理解你的模式和偏好
- 代表你做出决策
- 持续学习和适应
### 分身场景愿景
日程助手分身：
读取你的目标、项目、健康数据，生成真正符合你节奏的日程。
健康教练分身：
分析你的睡眠、运动记录，发现你自己不知道的模式。
职业顾问分身：
了解你的技能和经验，给出真正个性化的职业建议。
---
## 推荐工具思路 🛠️
如果你想开始构建自己的人生文件系统：
基础工具：
- Obsidian - 本地 Markdown 笔记
- Logseq - 大纲式笔记
- VS Code + Git - 代码编辑器管理人生
同步与访问：
- Syncthing - 点对点文件同步
- Nextcloud - 自托管云存储
AI 集成：
- Openclaw - 文件系统优先的 AI
- Claude Code - 可以直接操作文件的 AI
---
## 总结 📝
公司即文件系统
→ 人生即文件系统
→ AI 即分身
当你的 life 是一个统一的文件系统，
AI 拥有的不只是数据，
而是你的完整上下文。
它终于可以像代表公司一样代表你。
---
## 讨论 💬
如果你的人生是一个文件系统，
你的根目录会是什么样？
原文来自：
x.com
34 728
Chrome 146 包含 WebMCP 的早期预览版，可通过标志访问，它允许 AI 代理查询和执行服务，而无需像用户一样浏览 Web 应用程序。
服务可以通过命令式 navigator.modelContext API 声明，也可以通过表单以声明方式声明。
服务可以通过命令式 navigator.modelContext API 声明，也可以通过表单以声明方式声明。
8 03
今天 @歸藏 在 X 上回答了我的疑问，让一下豁然开朗，原来 Claude Code 的 Agents Team 特性，任何大模型都可以开启，无需制定 Claude Opus 4.6 之类。
这真是方便啊，可惜的是，如果是接入第三方就无法为具体的 Agent 选择具体哪个模型。
现在，我看着它们努力工作，露出了黑心老板的奸笑~
这真是方便啊，可惜的是，如果是接入第三方就无法为具体的 Agent 选择具体哪个模型。
现在，我看着它们努力工作，露出了黑心老板的奸笑~
8 01