Agentic Coding 深度解析：从架构原理到多 Agent 协作
AI 编程工具的演进，正在经历一次根本性的范式转变：从"补全光标处的代码"，到"自主完成端到端工程任务"。这种转变有一个专有名词——Agentic Coding。 围绕 Coding Agent 的讨论，常见两种极端：将其神化为自主智能体，或将其贬为"不过是提示词工程"。两种判断都失之简单。理解这个转变，需要从三个层面展开：工具层（OpenCode 的能力边界）、框架层（多 Agent 协作编排）、方法论层（如何让 Agent 真正服务于工程流程）。本文从真实的架构出发，拆解 Claude Code、OpenCode 等工具的实现模式，厘清各自的设计取舍，深入探讨子 Agent 的本质与多 Agent 协作的核心问题。 什么是 Agentic Coding 传统 AI 编程助手的工作模式是响应式的：开发者提问，AI 回答；开发者选中代码，AI 补全。人始终是执行者，AI 是辅助工具。 Agentic Coding 的工作模式是自主式的：开发者描述目标，Agent 自主规划步骤、调用工具、执行操作、验证结果，直到任务完成...
Graphify 深度解析：用知识图谱重新定义 AI 编码助手的代码理解能力
项目地址：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 等平台），核心做的事情只有一件：把任意文件夹变成一张可查询的知识图...
为什么你的"AI-First"战略可能是错的——CreaoAI 的全面重构实践
原文链接：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 能够有效地完成工作。 以下是原文的完整...
Anthropic Managed Agents 深度研究：解耦大脑与双手的架构哲学
原文链接：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（调用 Claude 并将工具调用路由到相关基础设施的循环）、Sandbox（Claude 可以运行代码和编辑文件的执行环境），并在此基础上通过**两个扩展维度——Many Brains（多...
Claude Code 源码深度解析：五层架构与核心设计模式
全景导图 %%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%% flowchart TD A[Entrypoints 入口层] --> B[Runtime 运行时层] ...
Compound Engineering：当 AI 工程从"模型调优"走向"系统组合"
2024 年之前，AI 工程的核心问题是"怎么让模型更好"。2024 年之后，核心问题变成了"怎么让多个组件协作得更好"。这个转变的名字叫 Compound AI Systems，而围绕它的工程学科叫 Compound Engineering。本文从"为什么单体模型不够"出发，系统梳理复合 AI 系统的架构模式、工程实践和与其他 Engineering 概念的关系。 一个类比秒懂 Compound Engineering 在讲技术之前，先用一个类比。 想象你要建一座现代化医院： 单体模型思维就像雇一个全科天才医生，让他一个人看所有病人——内科、外科、眼科、牙科全包。他确实很聪明，但一个人的精力和专业深度终究有限。 Compound AI Systems 思维就像建一个多科室协作的医院系统：有分诊台（路由器）、各科室的专科医生（专用模型）、病历档案室（检索器）、化验室（外部工具）、会诊机制（多智能体协作）。每个组件做自己最擅长的事，通过协作协议连接在一起。 Compound Engineering 就是设计和运营这...
Harness Engineering 完整指南：从 Prompt Engineering 到实践落地的三级跃迁
2020 年我们学会了跟模型说话（Prompt Engineering），2025 年我们学会了给模型喂信息（Context Engineering），2026 年我们学会了给模型搭脚手架（Harness Engineering）。这三个 Engineering 不是并列关系，而是严格的超集关系：PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角，系统梳理这条演进路径上的每一次范式跃迁，并给出从 Anthropic 实证到工程落地的完整方案。 一个类比秒懂三级跃迁 在讲技术之前，先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席： Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行，得说"用中火煎三分钟，翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统，让厨师在需要的时候拿到需要的东西...
OpenSpec 实战指南：从工作流到落地
为什么需要 OpenSpec 在 AI 编程时代，真正的难点往往不是“AI 会不会写代码”，而是“AI 能不能稳定写出你真正想要的代码”。问题往往不在模型能力，而在于需求、边界、约束和验收标准没有被稳定地表达出来。当意图没有沉淀为可复用的工程事实，AI 就只能在模糊上下文里“猜”。 OpenSpec 解决的正是这个问题。它的核心思想可以概括成一句话：先对齐规范，再生成代码（align before code）。与其把 AI 当成一个只看提示词的即时执行器，不如把它放进一套可追溯、可迭代、可沉淀的规范工作流里。 OpenSpec 既不是重量级流程平台，也不是传统瀑布式文档系统。从实践上看，它更像一套轻量的仓库内协议： 用 specs/ 保存系统当前已经成立的事实； 用 changes/ 保存本次准备引入的未来变化； 用 proposal、spec、design、tasks 把“为什么改、改成什么、怎么实现”拆开表达； 用 sync 和 archive 把一次变更逐步沉淀为下一次变更的上下文。 它的设计哲学，基本可以概括为四点： Fluid not rigid：规范是活文档，不...
子 Agent 的本质：上下文隔离与专门化
"子 Agent"这个词在多 Agent 系统的讨论中频繁出现，却鲜有人把它说清楚。它是一个能力弱化的 Agent，类似一个 Agent 化的工具？还是一个拥有更小上下文的原始 Agent，像从主 Agent fork 出来的进程？还是一个在指挥体系里听从领导 Agent、但拥有更强资源和能力的 Agent？ 这三种直觉都不完全准确。本文从 Anthropic、LangChain、Claude Code 等权威来源出发，厘清子 Agent 的真实本质，并探讨一个更深层的问题："子 Agent"究竟是能力描述，还是关系描述？ 三种直觉，三种误解 在深入定义之前，先把三种常见直觉逐一检验。 误解一：子 Agent 是能力弱化的 Agent 这种直觉来自于"子"字的字面含义——子集、子系统、子进程，往往意味着更小、更弱。但 LangChain 官方文档明确指出： “An interesting aspect of this approach is that sub-agents may have the exact sam...
git worktree 术语起源解析
引言 在使用 Git 的过程中，你可能会遇到 git worktree 这个命令。这个名字看起来有些特别——为什么叫 “worktree” 而不是 “workspace” 或其他更常见的词？这背后其实有一段有趣的技术历史。 核心答案 worktree 是 working tree（工作树）的缩写，来源于 Git 内部的核心概念。 这不是一个凭空创造的新词，而是直接引用了 Git 自诞生以来就存在的基础术语。 Git 的三大核心区域 要理解 worktree 的命名，首先需要了解 Git 的三大核心区域： 区域 英文名称 别名 作用 仓库 Repository - 存储所有版本历史和元数据（.git 目录） 工作树 Working Tree Working Directory 用户实际编辑文件的目录 暂存区 Index Staging Area 准备提交的文件快照 Working Tree 的含义 Working Tree（工作树）指的是检出（checkout）到文件系统中的文件集合。它是你能够直接看到、编辑的目录和文件。 12345my-project...
