最近看到一个很有意思的仓库：multica-ai/andrej-karpathy-skills。它看起来不像传统意义上的代码库，也不像一个可以直接运行的工具。里面没有复杂框架，没有业务代码，也没有什么炫目的工程实现。它更像是一组给 AI 编程助手准备的“行为准则包”。
但也正因为这样，我反而觉得它挺值得单独写一写。
很多 AI 编程工具现在都在强调更强的模型、更大的上下文、更快的代码生成。但这个仓库关注的方向刚好相反：它不是继续放大 AI 的生成能力，而是试图约束 AI 在工程现场里的行为方式。说得直白一点，它解决的不是“AI 能不能写代码”，而是“AI 写代码时能不能别太自信、别乱扩张、别跳过验证”。
最近读到小林coding那篇关于 Claude Code 多 Agent 实现机制 的文章。原文讲了三个关键机制：常规 Subagent、Fork Subagent 和 Coordinator 模式。
我读完之后更关心的是另一个问题：如果我们自己要构建一个 Multi-Agent 系统，应该从哪里下手？
我的结论是：Multi-Agent 不是“多放几个 Agent 互相聊天”，而是 Harness 在运行时创建多个隔离的执行单元，并用消息、权限和协调者把它们收敛起来。
最近看了一篇关于 Harness 工程的分享，文章表面上在讲怎么把 LLM Agent 的 prompt cache 命中率做到 90%+，但我读完之后更在意的，其实是它对 Multi-Agent 的一个反向提醒：
Multi-Agent 不应该被理解成“多几个角色就更智能”，它真正值得保留的价值，是上下文隔离和工程边界。
这件事很有意思。过去一年，大家谈 Agent 时很容易自然滑向 Multi-Agent：一个 Planner，一个 Coder，一个 Reviewer，一个 Tester，再加一个 Manager 做调度。这个结构看起来很像真实团队，也很符合人类对协作的直觉。但问题在于，模型不是人。把人类组织结构照搬到模型运行时里，未必会得到更好的系统，反而可能得到更高的成本、更长的链路和更多上下文损耗。
最近聊 AI 编程时，我发现一个很容易混在一起的问题：大家会同时提到 Agent 和 Harness，但很多时候并没有把这两个东西放在正确的位置上理解。
Agent 听起来像是主角，因为它能理解目标、拆任务、调用工具、读写文件、跑命令，甚至根据反馈自己调整下一步。Harness 听起来更像配角，因为它不直接“干活”，而是提供规则、流程、权限、上下文和校验。但如果真要把 AI 放进工程体系里，这两个概念其实缺一不可。
我自己的理解是：Agent 是能力内核，Harness 是工程护栏。Agent 决定 AI 能不能动起来，Harness 决定它能不能在正确的轨道上动起来。
这两年，很多团队都已经把 AI 带进了软件开发流程里。但如果仔细看，大多数所谓的“落地”，其实还停留在很浅的一层：写代码时开着 Copilot，遇到问题时问一下大模型，写文档时让它先起个草稿。它当然有帮助，但这种帮助更像是把 AI 当成一个更聪明的搜索框，而不是把它真正纳入工程系统。
我越来越觉得，AI 工程化真正要解决的问题，不是“开发者会不会用 AI”，而是“传统软件开发流程能不能被系统性改造，让 AI 在每个关键环节都稳定提高效率”。
这两者的差别很大。前者偏个人技巧，谁会提 prompt，谁更熟悉某个工具，谁就能多拿一点收益；后者偏组织能力，它关注的是流程是否可复制、结果是否可追踪、风险是否可控制、效率提升是否能从个人扩展到团队。
最近看到一条帖子，主题很抓人：一个 Plus 账号不够用，一个 Pro 账号又经常闲着，于是用 CLIProxyAPI 把多个账号组成本地代理池给 Codex 用。
如果只看表面，这像是在讲一个“3 分钟就能搭起来”的小技巧；但我觉得它真正值得聊的，不是教程本身，而是它背后的工程思路：当模型入口越来越多、账号形态越来越杂时，真正有价值的事情，不是再开一个入口，而是把这些入口组织成一个稳定可控的能力层。
很多人会把“代理池”理解成简单轮询，甚至直接联想到“中转站”。但对个人开发者或者小团队来说，更实际的意义其实是：把分散、零碎、时好时坏的模型访问能力，重新收束成一个本地可控的统一出口。
看完这篇对比 OpenClaw 和 Hermes 的文章，我的结论很简单：如果你还在问“谁替代谁”，大概率是把它们放错了维度。
它们确实都属于通用 Agent，也都在做 Skills、Memory、聊天入口、工具调用这些事。但真正的区别，不在功能清单，而在系统的厚度长在哪一层：OpenClaw 更偏入口、控制面和真实世界接入；Hermes 更偏执行循环、经验沉淀和跨任务复用。
表面上看，OpenClaw 和 Hermes 都能接聊天渠道、都能跑工具、都能保存记忆、都能通过技能扩展能力，所以很容易被当成“同类竞品”。
但这种比较方式有个问题：它只看到了“都能做什么”，没看到“主要在解决什么”。
对 Agent 系统来说，这两个问题不是一回事。一个系统可以把入口、消息路由、设备接入和权限治理做得很好，但不一定擅长把经验沉淀成可复用能力；另一个系统可以在长任务、技能复用和会话检索上做得很强，但不一定在多渠道接入和控制面上最顺手。
最近越来越多人喜欢用一个词来形容 AI 带来的变化：superpowers。
这个词很容易让人误解。因为一说“超能力”，很多人脑子里浮现出来的，还是那种很抓眼球的画面：一句提示词生成一个页面、几分钟写完一个脚本、十分钟做完一份 PPT、张口就给出一套看上去很完整的方案。
这些当然很惊艳，但如果只把 superpowers 理解成“原来 AI 能一下子帮我多干很多活”，那其实还是低估了这件事。
我现在越来越倾向于把它理解成另一层意思：
AI 时代真正的超能力，不是单次产出的魔术感，而是你能不能把模型能力稳定接进自己的判断、工作流和交付系统里。
这两者表面看起来都在用 AI，本质上却完全不是一回事。
最近看到一篇很长的文章，主题是 Harness 最佳实践：在 Java Spring Boot 项目中落地 OpenSpec + Claude Code。看完之后，我觉得它最有价值的地方，不是又介绍了一个“新概念”，而是把一件很多团队已经隐约意识到、但还没系统化表达的事情讲清楚了：
AI 真正要进入生产研发流程，重点从来不是“它能不能多写点代码”，而是“它能不能在边界内、按流程、可审计地工作”。
这也是我对 Harness 这个词最直白的理解：不是让 AI 更自由，而是让 AI 在工程规则里稳定工作。
