子 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 sa...
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...
告别 Vibe Coding:用 OmO 构建可靠的 AI 工程系统
引言:AI 编程的范式跃迁 过去一年,AI 编程工具从对话式代码生成器进化为能够自主执行复杂任务的智能代理。但真正的挑战不在于让 AI 写出代码,而在于如何让 AI 持续、可靠地完成工程任务。 Oh My OpenCode(简称 OmO)正是为了解决这一问题而生。它不是另一个聊天框,而是一套将 AI 从"对话工具"升级为"自动化工程系统"的编排框架。 OmO 的核心定位:工程化交付而非对话回答 从"会不会答"到"能不能交付" 传统 AI 编程工具的评判标准是"回答质量",而 OmO 的核心目标是**“工程交付”**。 OmO 的工作流程遵循"输入 Markdown 描述,输出可运行代码"的心智模型: 12341. 输入任务 → 2. 判断意图 → 3. 组织执行 → 4. 工程输出 (任务描述、 (Intent Gate (并行搜索、 (回到 build/ repo 上下文、 分清提问/修复/ 资料、执行...
智能体记忆全景综述:从短时长时之分到向量库回归文件系统(2022-2026)
22 年以前,“LLM 应用"基本等同于"调一次 ChatComplete”。从 22 年底 ChatGPT 出来到 26 年这三年里,行业发现真正决定智能体上限的不是模型本身,而是模型周围那一圈用来承载历史、外部知识与可更新偏好的记忆系统。这篇综述沿着一条主线展开:以"信息来源"为轴的四层记忆世界观,把过去三年的代表性工作放进这四层里,并且回答一个 26 年才浮出水面的反向问题——为什么大家又在把向量数据库塞回到一个 markdown 仓库或一份 SQLite 单文件里。 一、把整片版图压成三句话 如果把过去三年关于智能体记忆的所有论文、产品和工程实践压成三句话,大致是这样: 第一,Agent 的记忆按"信息源"切是一个稳定的四层结构:训练数据(L1)、对话内数据(L2)、会话间数据(L3)、外部世界但与本会话无关的数据(L4)。每一层的写入主体不同,分别是训练管线、当前交互、Agent 自己、世界本身。围绕"是不是要再切出第五层"在 25-26 年有一些讨论,本文的判断是:Titans / ...
在智能体优先的世界中利用 Codex
原文作者:Ryan Lopopolo,OpenAI 技术人员。本文记录了 OpenAI 内部一个工程团队历时五个月、以"零人工编码"方式构建并交付真实软件产品的完整经验。 在过去五个月里,我们的团队一直在进行一项实验:构建并交付一款软件产品的内部 beta 版,其中没有一行代码是人工编写的。 该产品有内部日常活跃用户和外部 Alpha 测试者。它经历了交付、部署、故障和修复的整个过程。与众不同的是,每一行代码 — 从应用逻辑、测试、CI 配置、文档、可观察性到内部工具 — 全都是由 Codex 编写的。据估计,我们只用了手工编写代码所需的大约 1/10 的时间就完成了这项工作。 人类掌舵。智能体执行。 我们有意选择这一限制,以便构建必要的内容,从而将工程速度提升数个数量级。我们用了几周的时间来交付最终达到一百万行代码的项目。为此,我们需要了解,当软件工程团队的主要工作不再是编写代码,而是设计环境、明确意图和构建反馈回路,从而使 Codex 智能体能够可靠地工作时,会发生哪些变化。 这篇文章要说的是,在我们与智能体团队一起从零开始打造一款全新产品的过程中,所...
macOS CLI 工具 HTTPS 抓包指南(以 OpenCode 为例)
为什么需要 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 - 带注释的 JSON
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,部分工具归因和优先级已经过时。稳定的时态分类、载体边界和组合方法已迁入新文章;本页保留原 URL 作为迁移索引。 配置文件不宜只按扩展名分类。更可靠的坐标系包含五类组件:内容源、选择器、上下文装配器、执行器和生命周期管理器。AGENTS.md 与 CLAUDE.md 是项目指令载体,Rules 负责作用域选择,Skill 是可调用能力包,OpenSpec 管理需求与变更状态;各工具对目录、优先级和动态加载的支持需要分别核验。 内容迁移表 原文主题 当前专题 文件、组件、作用域、装配顺序与时态分类 AI Coding Agent 的上下文栈:组件边界与装配顺序 Rules、Commands、Skills、Hooks、Plugins 的演变 从 Rules 到 Agent Skills:能力加载机制的演变 AGENTS.md 的内容边界、骨架与维护 如何写好 AGENTS.md Skill 的目录、路由、正文和恢复 AI Coding Agent 的 ...
QMD:本地智能文档搜索引擎完全指南
QMD:本地智能文档搜索引擎完全指南 引言:你的知识库需要一把钥匙 作为程序员、写作者或知识工作者,我们每天都在产生大量的 Markdown 文档——技术笔记、会议记录、项目文档、博客草稿……这些文档散落在不同的文件夹中,随着时间推移,它们变成了"数字废墟":你知道某篇笔记一定存在,却怎么也找不到。 传统的文件搜索工具(如 Spotlight、grep)只能基于文件名或关键词匹配,无法理解语义。而云端笔记工具(如 Notion、Obsidian)虽然提供了搜索功能,却存在数据隐私和访问限制的问题。 QMD(Query Markup Documents) 正是为了解决这个痛点而生的——一个完全本地运行的智能文档搜索引擎,它结合了 BM25 全文检索、向量语义搜索和 LLM 重排序,让你能够用自然语言快速找到任何文档中的任何内容。 一、QMD 是什么 QMD 是一个开源的 CLI 工具 + 库,由 @tobi 开发,专为 Markdown 文档设计。它的核心特性包括: 特性 说明 完全本地 所有数据和模型都在本地运行,无需联网 混合搜索 BM2...
LSP:语言服务协议与AI编程助手的代码理解能力
LSP:语言服务协议与AI编程助手的代码理解能力 早期的 AI 编程工具,本质上是在做文本替换:把代码当作字符串,在字符串层面做补全、修改、搜索。这种方式有一个根本缺陷——它不理解代码的结构。 一段 Java 代码里,UserService 是一个类,findById 是它的方法,返回类型是 Optional<User>。文本替换工具看到的只是这些字符;而一个真正理解代码的工具,能够知道: findById 的参数类型是 Long,不是 String 调用这个方法的地方有 12 处,分布在 5 个文件里 如果修改了方法签名,哪些调用点会编译失败 这种理解能力,来自 LSP(Language Server Protocol)。 LSP 是什么 LSP 是微软在 2016 年提出的协议(Language Server Protocol 官方规范),目的是把"语言智能"从编辑器中解耦出来。 在 LSP 出现之前,每个编辑器都要为每种语言单独实现代码补全、跳转定义、查找引用等功能。VS Code 要实现一套,Vim 要实现一套,Emacs 要实现一套—...








