杀死扣子的不是dify，而是workbuddy和deepseek harness
没啥用，已经这么做都半年多了
腾讯开源了一个 TeamAI-CLI，做法很简单：把团队使用 Agent 的规则、Skill 和文档，直接放进一个 Git 仓库。
谁摸索出了一套更好用的方法，就像改代码一样提交；团队评审之后再合并，下一次对话便同步给每个人。哪条规则是谁改的、为什么改、效果不好怎么退回去，也都有记录可查。
我觉得这个思路挺正。
现在一提团队知识共享，很多人上来就想搭知识库、设计复杂的分类体系，再做一套管理后台。
但真正的问题往往没有那么复杂，大家各自在电脑上踩坑。
知识一旦进入协作，首先需要解决的其实就是变更、评审、版本和溯源。而这些问题，Git 已经解决得很好了。
过去我们用 Git 管理团队共同生产的代码，现在开始用它管理团队共同使用 AI 的方法。
方案看起来很轻，抓住的却是最核心的问题。
没那么复杂。根目录建一个claude.md指向agents.md软连接，然后者里面约定各级目录都指定使用它就行了。
🚨突发，Shopify CEO Tobi Lütke 公开向 Anthropic 施压！
Tobi称 如果 Claude Code 继续拒绝读取 AGENTS.md 和 .agents/skills，他正在考虑直接在 Shopify 内部禁用 Claude Code。
Tobi 给出的原因很现实。
现在一个工程团队里，大家可能同时用 Codex、Cursor、Claude Code 等不同 Coding Agent。
越来越多工具开始读取统一的 AGENTS.md，团队可以把项目规范、测试方式、开发约定和 Agent 指令放在一个地方。
但 Claude Code 目前主要依赖自己的 CLAUDE.md 和 .claude/skills。
结果就是，同一个代码仓库，不同 Agent 可能读到两套完全不同的规则。
Tobi 把这种情况直接称为 split brain（脑裂）。
对于个人开发者，多维护一个文件可能没什么。
但对 Shopify 这种大量工程师同时使用 AI Coding 工具的公司，这意味着团队需要长期同步两套 Agent Context，一旦不同步，Agent 的行为就可能出现偏差。
所以这件事看起来只是一个 Markdown 文件之争，背后其实是 Coding Agent 正在进入企业之后必然遇到的问题。
Agent 的项目配置、Skills 和 Context，到底应该属于某一家模型公司，还是成为所有 Agent 都能读取的公共标准？
现在 Shopify 已经开始用公司级采购权给出自己的答案了。
Claude Code 模型再强，企业也不会愿意为了一个工具长期维护一套平行的工程规范。
PS：有没有人写个插件自动把claude.md转成agents.md
解决的是真问题，但长期来看会被模型平台吞噬。
未来的agent runtime一定会包含这块。
开源项目 LoopX：超长程 Agent 自主运行 200+ hours，状态不漂移。
我的技术主张是：LLM 上下文有限，长程 Agent 需要外置状态，通过完备的状态管理、监督和规划，让 Agent 无人干预时跑得稳、持续有产出；有人干预时跑得更好，能吸收反馈继续演进。
两条真实 trajectory 分别跨越 220.7 / 272.9 小时，跨多轮执行、等待、人工决策、writeback 与 resume 后，整个 loop 仍能找回目标、证据和下一步。
目前 LoopX 已有 3 个 showcase：auto PR issue fix、AutoML experiment 和 auto coredump fix。
以 OpenViking 开源仓库的 PR issue fix 为例，Agent 不只是循环写代码。它需要持续理解 issue 的不同状态，判断何时开发、何时等待、何时请求 review，处理 CI、冲突和上游变化，并连续交付多个 PR。
这对应 LoopX 的 domain state 管理：领域系统决定真实状态，LoopX 负责把状态投影成下一步可执行的工作。
与此同时，Agent 还可以在干活过程中实现能力自进化。当它发现现有系统缺少某项能力时，可以提出 feature、完成开发与验证、发布新的离线或在线版本，再使用新能力继续原来的任务。
长程 Agent 天然适合自进化，“完成工作”和“升级完成工作的系统”可以在同一条长程轨迹中发生。
LoopX 把这些信息外置成结构化控制面：
• Goal / Vision：目标是什么，什么不能被局部优化牺牲
• Todo / Gate：当前执行的 frontier，以及必须留给人的关键判断
• Identity / Authority：谁能 claim、writeback、approve
• Evidence / Receipt：每次推进留下什么可回读证据
• Quota / Scheduler：何时继续执行，何时安静等待
• Handoff / Recovery：换模型、换会话、换 host 后如何恢复
你也可以把它理解为一块专门给 Agent 设计的可执行 Kanban。
普通看板只展示“谁在做什么”；LoopX 的状态会直接约束和驱动下一次 bounded turn，让看板本身成为执行系统的一部分。
这套系统最强的地方是通用性。它不只可以修 PR，还可以做 auto research、长期实验、自媒体运营、复杂 feature 开发和办公任务。
Agent 不再只是一次性的回答机器，而可以围绕一个人的 vision，长期工作、等待、吸收反馈、积累证据并持续演进。
LoopX 从一开始 build in public：状态协议、CLI、控制面实现和真实运行轨迹都进入了开源仓库；它也已经和 OpenViking、NoKV 等 agent infra 项目形成了开源合作伙伴关系。
我希望 LoopX 最终能放大每个人的 vision 和想象力。只要你有自己的目标、想法或技术主张，就能拥有一个全天候继续工作和探索的 Agent 系统，帮助你把愿景一点点变成现实。
欢迎试用、提 issue、贡献代码，或者用一个真实的 multi-day task 跑 LoopX。
github.com/huangruiteng/loop…
最近发现了一个导致claude code产生大量幻觉和错误的工具调用的根本原因。
CC默认对模型输出的长度限制为64K，但是当你把模型设置为1M上下文的模型（比如opus 4.8），effort为xhigh或者更高的时候，就会有比较大的概率输出超过了64K导致被截断，而CC又自动脑补了截断部分内容。
血泪教训:千万别开 Claude Code 的 tui: fullscreen。
我48G M4 Pro 卡到不行,查半天发现是它把 macOS WindowServer 逼进 CPU 渲染(GPU 0%)。改回默认模式就好了。
高刷+高分屏(XDR/ProMotion)尤其容易中招。
Annual totals tell a story, but not the whole story. Responsibility depends entirely on the accounting lens you choose.
汽车发明的时候，马车也是这么评价的吗？
Linus Torvalds 发飙了。
他在开源峰会上公开吐槽，每次听到有人吹嘘“现在 99% 的代码都是 AI 写的”，他就忍不住生气。
为什么？
因为按这个逻辑，这些家伙 100% 的代码其实都是“编译器”生成的。
但他们怎么从来不这么说？
其实是一个道理。
老爷子在台上开始唠家常：
“我是写机器码长大的。”
注意，不是汇编语言，是真正的数字。
他到现在都记得，在 6502 芯片上，LDA 指令对应的十六进制是 A9。
当年他花了好长时间才意识到，天天人肉算跳转偏移量，简直蠢透了。
后来，人类发明了汇编器；
再后来，有了编译器；
现在，有了 AI。
这些工具都很好用，AI 正在改变编程，但它绝没有改变编程的根本。
至于 AI 带来的“效率神话”？
Linus 给出对比：
“AI 很棒，它能把你的生产力提升 10 倍。”
“但当年编译器的出现，把人类的生产力提升了 1000 倍！”
所以，这不过是又一次常规的工具演进。
事情的本质从未改变：
以前，优秀的开发者写出好代码，差劲的开发者写出 Bug。
现在，懂系统的人能用 Prompt 调教 AI 写出好代码；
而不懂系统复杂度的人，用 AI 攒出来的代码，最后一定会崩溃。
现在科技圈很流行“氛围编码”（Vibe Coding）。
就是用 AI 啪啪生成一个一次性项目，爽一把就扔。
Linus 说，这种玩具项目，AI 的确是神器。
但如果你想做点严肃的东西，做一个需要长线维护 35 年的系统（比如 Linux）。
你得懂你的 Prompt。
你必须看懂 AI 吐出来的每一行代码，甚至去盯它最底层的汇编结果。
祖师爷浇了盆冷水：
AI 可以替你省去体力劳动。
但如果你连它写了什么都看不懂，那你永远只是在制造一次性垃圾。
Claude Code 答非所问，往往不是模型变笨——是 harness 用「模型看到的上下文」去理解你的意图，而那份上下文被它自己的工具噪音按十倍灌满。
你的意图，应该建立在「你终端上真正看到的那份对话」之上。
这是我最近发现的最大幻觉来源——它幻觉的不是事实，是一个你从没下达的任务。
记住这些命令=回到命令行时代
现在的cc唯一问题就是命令太多了
@bcherny
实践哥这个神级的skill 迟早要被Claude Code官方开发出来的，就看时间了。
让我想起来几个比较常用的指令：
1、/btw ：临时插入问一个旁路问题，但不写进对话历史，主线上下文不会被污染。
2、/model ：会话中途切模型，上下文缓存全部丢失。
3、/clear：清空了我们输入的上下文。
4、/export：把聊天记录导出，在其他模型里导入使用
context
5、 subagent：主 agent 发指令给 subagent，无缓存继承。workflow 用的大量 subagent。
6、/branch ：在当前位置给对话开一个分支并把你切进去，原会话原样保留，随时可用 /resume 回去。
7、/fork ：派一个继承全部上下文的后台分身(SubAgent)去办这一件事，你继续留在主线干活，它做完把结果自动带回你的对话。
8、 claude --continue --fork-session： 在当前目录执行，会 复制出一个最近对话的上下文。100% 缓存。而跟上面/fork是在会话中使用的，而我们这个相当于启动cli的时候。
9、 ⌘F：本文介绍的 skill，比第七个更强，在对话过程中直接弹出旁窗，复制上下文，进行新对话。100% 缓存。
最后第九个最牛逼的就是完全开辟并新增了一个单独的旁路窗口，可以跟原窗口直接并行执行。
上面其实也涉及到worktree，这里等下次有机会再整理一下。