守株阁

"子 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...

网上关于 Coding Agent 的讨论，要么神化它，要么把它贬成"不过是提示词工程"。这两种说法都不够准确。本文从真实的架构出发，拆解 Claude Code、OpenCode 等工具的实现模式，厘清它们的优缺点，以及那些被反复误解的核心问题。 一个循环统治一切 先说结论：所有 Coding Agent 的核心，都是一个 while(tool_use) 循环。 通过对 Claude Code 实际 API 流量的追踪分析，其核心逻辑可以用伪代码描述如下： 12345678while True: response = llm.call(context) if response.has_tool_call(): result = execute_tool(response.tool_call) context.append(result) else: # 没有工具调用 = 任务完成，等待用户输入 break 没有复杂的状态机，没有多 Agent 协调框架，没有专门的"停止决策...

引言 在使用 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...

引言：AI 编程的范式跃迁 过去一年，AI 编程工具从对话式代码生成器进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码，而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode（简称 OmO）正是为了解决这一问题而生。它不是另一个聊天框，而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位：工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量"，而 OmO 的核心目标是**“工程交付”**。 OmO 的工作流程遵循"输入 Markdown 描述，输出可运行代码"的心智模型： 12341. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出 (任务描述、 (Intent Gate (并行搜索、 (回到 build/ repo 上下文、 分清提问/修复/ 资料、执行...

上一篇文章讨论了 Harness Engineering 的本质——它依赖外部记忆让任务执行可接力。本文继续深入：外部记忆有没有标准的文件格式？它除了用在 Harness Engineering 里，还有哪些更广泛的用途？ 外部记忆的文件标准：现状与混沌 先说结论：目前没有一个被所有主流 AI 工具统一采纳的外部记忆文件标准，但已经出现了若干事实标准（de facto standards），并且正在快速收敛。 为什么标准化很难 外部记忆文件的标准化面临一个根本性的困难：不同的 AI 工具、不同的任务类型、不同的团队规模，对"需要记住什么"的答案是不同的。 一个用于代码生成的智能体需要记住架构约束、代码规范、依赖关系；一个用于客户服务的智能体需要记住用户偏好、历史交互、业务规则；一个用于科学研究的智能体需要记住实验假设、已验证的结论、待验证的方向。 这种多样性使得"一个文件格式统治所有场景"几乎不可能。 当前的事实标准 尽管如此，业界已经形成了几个被广泛认可的文件约定： AGENTS.md / CLAUDE.md / CURSOR_RU...

本文尝试回答一个在智能体工程实践中反复出现的问题：Harness Engineering 到底是不是长任务的必备解法？它的本质是什么？它与外部记忆又是什么关系？ 从一个根本性的困境说起 想象一个场景：你让一个 AI 智能体去构建一个完整的 Web 应用。它开始工作，写了几个小时的代码，然后——上下文窗口满了。 新的一轮对话开始了。这个智能体对之前发生的一切一无所知。它看到了一堆代码，但不知道哪些功能已经完成、哪些还在半途、哪些已经被测试过。它只能猜测，然后继续——很可能在错误的方向上继续。 这就是长任务智能体面临的核心困境：上下文窗口是有限的，而复杂任务是无限的。 Anthropic 在 2025 年 11 月发布的工程博客 Effective harnesses for long-running agents 中，将这个问题描述得非常形象： 想象一个软件项目由轮班工程师负责，每个新工程师到来时对上一班发生的事情毫无记忆。 这不是比喻，这就是当前所有 AI 智能体在跨越上下文窗口时的真实处境。 Harness Engineering 是什么 “Harness"...

原文作者：Ryan Lopopolo，OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里，我们的团队一直在进行一项实验：构建并交付一款软件产品的内部 beta 版，其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是，每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计，我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制，以便构建必要的内容，从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此，我们需要了解，当软件工程团队的主要工作不再是编写代码，而是设计环境、明确意图和构建反馈回路，从而使 Codex 智能体能够可靠地工作时，会发生哪些变化。 这篇文章要说的是，在我们与智能体团队一起从零开始打造一款全新产品的过程中，所...

为什么需要 CLI 抓包？ 在开发调试 AI 编程助手、API 客户端等命令行工具时，经常需要查看其 HTTPS 请求内容。浏览器有开发者工具，但 CLI 工具的流量对开发者是"不可见"的。本文介绍如何使用 mitmproxy 在 macOS 上实现 CLI 工具的 HTTPS 抓包。 工具选择 在 macOS 上对命令行工具进行 HTTPS 抓包，免费方案首选 mitmproxy。它提供三种使用形态： mitmproxy：终端交互式 UI，适合实时过滤和查看 mitmweb：浏览器 Web UI，JSON 自动格式化，适合内容分析 mitmdump：纯命令行，适合录制流量到文件或脚本处理 三者共享同一套证书和配置，按需选用即可。 安装 1brew install mitmproxy 第一步：生成 CA 证书 首次运行会自动生成证书文件： 12mitmproxy# 看到界面后直接 q 退出 证书默认生成在 ~/.mitmproxy/： 1234~/.mitmproxy/├── mitmproxy-ca-cert.pem # 需要信任这个├── mitm...

JSONC 是什么？ JSONC（JSON with Comments）是 JSON 的一个扩展格式，允许在 JSON 数据中添加注释。这个规范由 jsonc.org 定义，旨在形式化一种在实践中广泛使用但缺乏正式标准的格式。 起源与背景 JSONC 格式最初由微软非正式地引入，用于 VS Code 的配置文件，包括： settings.json - 编辑器设置 launch.json - 调试配置 tasks.json - 任务配置 伴随着这种非正式格式，微软发布了一个公开可用的解析器 jsonc-parser。JSONC 规范的目标是将 JSONC 格式形式化，定义 jsonc-parser 在默认配置下认为有效的内容。 语法规则 JSONC 遵循与 JSON 相同的语法规则，并额外支持 JavaScript 风格的注释。 单行注释 单行注释以 // 开始，延伸到行尾： 12345{ // 这是单行注释 "name": "John Doe", "age": 30} 多行注释 多行注释以 ...

AI 编程工具的普及带来了一个新问题：项目里到处都是 .md 文件。AGENTS.md、CLAUDE.md、rules/、openspec/……它们各自解决什么问题？边界在哪里？什么时候该用哪一个？ 这篇文章的核心洞察是：这些配置文件可以用"核心问题"和"时态属性"两个维度来区分——前者决定它们解决什么层面的问题，后者决定它们适合承载什么类型的信息。 理解这两个维度，就能在配置文件的迷宫中找到方向。 一、背景：为什么需要这么多配置文件？ 传统软件项目只需要一个 README.md——它是给人读的。但在 AI 编程时代，项目需要同时面向两类读者：人类和 AI Agent。 人类需要的是高层次的概览（“这个项目是做什么的？”），而 AI Agent 需要的是结构化的、可执行的上下文（“代码在哪里？怎么跑起来？有哪些约束？”）。这两类需求差异巨大，单一文件难以同时满足。 于是，项目配置文件开始分化。每一类配置文件都针对特定的问题域，服务于特定的 AI 工具或工作流。理解它们，就是理解 AI 编程工具的协作边界。 二、目录结构：一个典型 AI 项目...