守株阁

AI 编程工具的演进，正在经历一次根本性的范式转变：从"补全光标处的代码"，到"自主完成端到端工程任务"。这种转变有一个专有名词——Agentic Coding。 围绕 Coding Agent 的讨论，常见两种极端：将其神化为自主智能体，或将其贬为"不过是提示词工程"。两种判断都失之简单。理解这个转变，需要从三个层面展开：工具层（OpenCode 的能力边界）、框架层（多 Agent 协作编排）、方法论层（如何让 Agent 真正服务于工程流程）。本文从真实的架构出发，拆解 Claude Code、OpenCode 等工具的实现模式，厘清各自的设计取舍，深入探讨子 Agent 的本质与多 Agent 协作的核心问题。 什么是 Agentic Coding 传统 AI 编程助手的工作模式是响应式的：开发者提问，AI 回答；开发者选中代码，AI 补全。人始终是执行者，AI 是辅助工具。 Agentic Coding 的工作模式是自主式的：开发者描述目标，Agent 自主规划步骤、调用工具、执行操作、验证结果，直到任务完成...

项目地址：safishamsi/graphify（⭐ 27.6K） 版本：v4（截至 2026-04-16） 一句话总结：把代码、文档、论文、截图丢进去，生成一张可查询的知识图谱，让 AI 编码助手从"逐文件 grep"进化到"按图索骥"。 你有没有过这样的体验——在 Claude Code 里问一个架构问题，它花了 80% 的 token 在 Glob 和 Grep 上翻文件，最后给你一个似是而非的答案？ 这不是 AI 不够聪明，而是它看不到全局。 Graphify 就是来解决这个问题的。它不是又一个 RAG 工具，不是又一个向量数据库，而是一个面向 AI 编码助手的知识图谱构建技能——用确定性的 AST 解析 + LLM 语义提取，把你的代码库压缩成一张结构化的图，然后让 AI 先看地图再找路。 它到底是什么 Graphify 是一个 Claude Code skill（现在也支持 Codex、OpenCode、OpenClaw、Factory Droid、Trae 等平台），核心做的事情只有一件：把任意文件夹变成一张可查询的知识图...

原文链接：Why Your “AI-First” Strategy Is Probably Wrong 作者：Peter Pang（CreaoAI 联合创始人，前 Meta LLaMA 团队） 发布时间：2026-04-13 翻译与总结：2026-04-15 前言 这篇文章来自 Peter Pang 在 X（Twitter）上发布的长文，发布后迅速获得了 3100+ 点赞、9300+ 收藏、160 万+ 阅读，引发了广泛讨论。 Peter Pang 是 CreaoAI 的联合创始人，此前在 Meta 参与 LLaMA 项目。CreaoAI 是一个 Agent 平台，仅有 25 名员工、10 名工程师。他在文中详细描述了如何将整个公司的工程流程、产品流程、测试流程围绕 AI 进行彻底重构，而不是简单地"在现有流程上加一个 AI 工具"。 这篇文章的核心观点与 OpenAI 在 2026 年 2 月提出的 Harness Engineering（驾驭工程） 概念高度一致：工程团队的首要工作不再是写代码，而是让 Agent 能够有效地完成工作。 以下是原文的完整...

原文链接：Scaling Managed Agents: Decoupling the brain from the hands 研究时间：2026-04-14 研究方法：多轮迭代搜索 + 交叉验证 + 结构化综合 前言：从"程序即未设想之物"说起 Anthropic 在 2026 年 4 月发布的 Managed Agents 服务，解决了一个经典的计算机科学问题：如何为"尚未设想的程序"设计系统。 这个问题的答案，早在几十年前操作系统设计时就已经给出——通过虚拟化硬件为通用抽象（进程、文件），使得 read() 系统调用既能访问 1970 年代的磁盘组，也能访问现代 SSD。抽象层保持稳定，底层实现自由演进。 Managed Agents 做了同样的事情：将 Agent 组件虚拟化为三个核心抽象——Session、Harness、Sandbox，使得未来的 Harness 实现、Sandbox 技术或上下文工程策略都可以独立演进，而接口保持稳定。 本文是对这篇工程博客及相关技术的深度研究报告。 一、核心架构：三层解耦设计 1.1 ...

全景导图 %%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%% flowchart TD A[Entrypoints 入口层] --> B[Runtime 运行时层] ...

2024 年之前，AI 工程的核心问题是"怎么让模型更好"。2024 年之后，核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems，而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发，系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前，先用一个类比。 想象你要建一座现代化医院： 单体模型思维就像雇一个全科天才医生，让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明，但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统：有分诊台（路由器）、各科室的专科医生（专用模型）、病历档案室（检索器）、化验室（外部工具）、会诊机制（多智能体协作）。每个组件做自己最擅长的事，通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...

2020 年我们学会了跟模型说话（Prompt Engineering），2025 年我们学会了给模型喂信息（Context Engineering），2026 年我们学会了给模型搭脚手架（Harness Engineering）。这三个 Engineering 不是并列关系，而是严格的超集关系：PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角，系统梳理这条演进路径上的每一次范式跃迁。 一个类比秒懂三级跃迁 在讲技术之前，先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席： Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行，得说"用中火煎三分钟，翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统，让厨师在需要的时候拿到需要的东西。 Harness Engineering 就是学会怎么...

当我们让 AI Agent 实现一个功能，它思考了一下，开始写代码。200 行写完，运行 lint 直接失败。我们发现类型定义文件 import 了配置包，但是违反了我们期望的架构分层约束，因为 Agent 不知道这个规则，当然我们也没告诉它。 于是它开始修复：移动代码、调整依赖、重新组织。再跑 lint——又一个新问题。循环三次后，上下文窗口被错误日志和 diff 塞满，Agent 开始"忘记"最初的任务目标。 这不是 Agent 不够聪明。这是 Agent 看不见。 你可能也遇到过类似的事情：同一个项目，昨天的 AI 还记得你们的架构约定，今天开个新会话又全忘了。每次协作都要重新解释一遍背景、分层规则、命名规范。AI 生成的代码能跑，但完全不符合团队规范，code review 时才发现一堆问题。让它修 bug，结果引入了新 bug——没有自动验证，全靠人肉检查。 如果换成一个新入职的工程师，他可能也不熟悉代码库，但至少会问一句：“这个文件应该放在哪个目录？”"这样 import 可以吗？"他在行动前寻求验证。AI Agent 不会。它...

原文：Harness design for long-running application development 作者：Prithvi Rajasekaran，Anthropic Labs 团队成员 发布日期：2026 年 3 月 24 日 Harness 设计是前沿 Agent 编程性能的关键所在。本文介绍我们如何在前端设计和长时自主软件工程两个方向上，将 Claude 的表现大幅推进到基线之上。 过去几个月，我一直在研究两个相互关联的问题：如何让 Claude 生成高质量的前端设计，以及如何让它在无人干预的情况下构建完整的应用程序。这项工作源于我们早期在前端设计 Skill 和长时编程 Agent Harness 上的探索——通过提示词工程和 Harness 设计，我和同事们将 Claude 的表现大幅提升到了基线之上，但两个方向最终都遇到了瓶颈。 为了突破这一瓶颈，我寻找了在两个截然不同领域都能奏效的新型 AI 工程方法——一个领域以主观审美为核心，另一个以可验证的正确性和可用性为核心。受生成对抗网络（GAN）的启发，我设计了一种包含生成器和评估器 Agent 的...

为什么需要 OpenSpec 在 AI 编程时代，真正的难点往往不是“AI 会不会写代码”，而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力，而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实，AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话：先对齐规范，再生成代码（align before code）。与其把 AI 当成一个只看提示词的即时执行器，不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台，也不是传统瀑布式文档系统。从实践上看，它更像一套轻量的仓库内协议： 用 specs/ 保存系统当前已经成立的事实； 用 changes/ 保存本次准备引入的未来变化； 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达； 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学，基本可以概括为四点： Fluid not rigid：规范是活文档，不...