守株阁

Multi-Agent 在 2026 年成了一个被过度使用的词。有人把三个 LLM 调用串起来就叫 Multi-Agent，有人把 prompt chaining 换了个名字就叫 Multi-Agent。在这层噪音下面，真正的问题是：什么条件下必须让多个独立智能体协作？它们之间怎么组织？组织错了会付出什么代价？ 本文的目标不是介绍各种框架，而是回答一个更前置的工程判断：你的任务到底需不需要 Multi-Agent，如果需要，选哪种组织模式损耗最小。 先搞清楚概念：不是所有多次 LLM 调用都叫 Multi-Agent 四层能力光谱 1234L1 Single Agent 一个模型 + 工具循环L2 Agent + Skills 同一模型通过 MCP/RAG/Memory 扩展L3 Multi-Agent Workflow 多个独立模型，编排逻辑写在代码里L4 Agent Teams 多个独立模型，编排逻辑由模型自己决定 核心判据：谁持有执行流的控制权。 L1-L2 始终是单模型决策。L3 有多个模型参与，但它们按...

一句话结论 Context7 就是 AI 时代的 GrepCode。没有别的什么东西了。 如果你没经历过 GrepCode 时代，或者对这个类比不够确信——下面展开讲。 GrepCode：一段被遗忘的基础设施史 2010 年前后，Java 生态里有个网站叫 GrepCode（grepcode.com）。它做的事很朴素：把 Maven Central 上几乎所有公开 artifact 的源码按版本全部索引起来，提供一个在线搜索界面。 你可以搜 org.springframework.context.ApplicationContext，它会列出 Spring Framework 从 2.x 到 5.x 每个版本里这个接口的完整源码。你可以点进 3.2.18 看一版，再点进 4.0.0 看另一版，对比方法签名的变化、新增的注解、废弃的参数。它甚至支持交叉引用——点一个类型就能跳转到依赖库对应版本的实现。 GrepCode 本质上是一个带版本维度的、面向人类开发者的代码知识检索服务。 开发者什么时候用它？不是写新功能的时候——而是遇到版本兼容性问题的时候。“这个方法在 Spring ...

2026 年的 AI 编程工具生态中，单模型 CLI 已不再是终点。围绕 Claude Code 和 OpenCode 两大基座平台，不仅各自拥有原生的多 Agent 并行能力（Claude Code 的 Subagents 与 Agent Teams、OpenCode 的 Primary Agents 与 Subagents），还分别涌现出 oh-my-claudecode（OMC） 和 oh-my-openagent（OmO） 两个重量级多 Agent 编排插件。两者 GitHub star 数合计超过 9 万，代表了当前 Agentic Coding 编排层的两种核心思路：单模型深度增强 vs 多模型原生编排。 本文从基座原生能力讲起，逐步深入到插件层架构，对四种工作模式进行全维度对比，并提供可直接上手的实用教程与最佳实践决策指南。 TL;DR：日常命令选择指南 如果你只想知道"该用哪个命令"，看这一节就够了。后面的章节是架构原理的深度解析。 OMC（Claude Code 生态） 123456789101112131415161718192021你...

调研截至：2026-05-20。本文从 patleeman 的 Codex /goal PR 解析和 36氪 / 新智元关于 Ralph Loop 产品化的报道出发，交叉核对 OpenAI Codex、Claude Code、Hermes、Anthropic Ralph Loop、OpenCode / Oh My OpenCode、Oh My ClaudeCode、自进化 Agent 相关论文与公开资料，并对一个内部 all-in-one SDD skill 做了脱敏分析。脱敏约定：不写本地路径、组织名称、平台名称、具体适配器名和领域字段；下文用 sdd-all 指代这类内部 SDD overlay。 Goal 模式不应再被理解为 Codex 的单点能力。更准确的判断是：AI 编程工具正在把 Ralph Loop 这类外部循环，收敛成一类更正式的闭环交付控制协议。 先把 Ralph 循环的一句话定义放最前面 Ralph 循环 = 外层循环 + 稳定锚点提示词 + 外置完成判定器 + 外部可恢复进度态。 四件套缺任意一件，Ralph 都会塌成别的东西。展开来说： 部件 ...

一句话定义 多模态模型，就是能同时理解、关联和处理多种信息形态的 AI 模型。这里的“多种信息形态”包括文本、图片、音频、视频、表格、传感器数据等。 这句话里最容易被忽略的是“关联”。如果一个系统只是分别接了 OCR、语音识别、图像分类三个模块，再把结果拼在一起，那更像多工具流水线；真正的多模态模型要解决的是：不同形态的信息如何落到同一套语义判断里。 什么是“模态” 模态（modality）指信息被承载和组织的形式。不同模态不只是文件格式不同，而是底层结构、统计规律、抽象路径都不同。 模态 例子 原始形态 典型结构 文本 文章、对话、代码 字符 / token 序列 一维离散序列 图像 照片、截图、图表 像素矩阵 二维空间结构 音频 语音、音乐、环境声 波形 / 频谱 时间序列 视频 短视频、监控画面 图像帧 + 音频 + 时间 时空序列 结构化数据 表格、指标、传感器读数 字段、行列、时间戳 schema 约束下的结构 所以，“模态”的核心不是“输入文件扩展名”，而是信息在进入模型之前，本来是以什么结构存在的。 单模态与多模态的区别 单模态...

结论：中国约 491 万亿元，美国约 101 万亿美元 把居民、非金融企业、政府、金融四大部门的债务全部加起来，中美两国的社会总债务大致如下： 中国 美国 全社会总债务 ~491 万亿元（~68 万亿美元） ~101 万亿美元 总债务 / GDP ~351% ~325% 非金融部门数据来源：BIS Total Credit to the Non-Financial Sector（2025 Q3）及美联储 Z.1（2025 Q4）。金融部门数据参考 IIF Global Debt Monitor 口径估算。中国 GDP 取国家统计局 2025 年初步核算数 140.19 万亿元，美国 GDP 约 31 万亿美元。 中国的总债务绝对量低于美国，但占 GDP 的比例反而高出约 26 个百分点。两国都不是低债务经济体，差距的根源在结构。 四大部门拆分：钱是谁借的 部门 中国（占 GDP） 中国（万亿元） 美国（占 GDP） 美国（万亿美元） 居民 ~60% ~84 ~67% 20.9 非金融企业 ~167% ~234 ~72% 22.2 ...

生成时间：2026-05-07 目标：在不改 sandbox 镜像、不动 某企业级 Agent 框架 存量 system prompt 的前提下，把自研 SDD 流程（自研 SDD 流程 / 自研 SDD 流程）稳定塞进 OpenCode，让它在每个项目里都能可复现地盖过默认 openspec-* 流程。 适用读者：希望在某 sandbox 平台 内做 agent 行为定制的开发者 综合来源：3 份前置探索文档（配置体系探索之旅 / Sandbox 配置全解 v4 / 需求澄清流程控制实验） 0. TL;DR 自研 SDD 被默认 openspec-* 盖掉，根因不是权限不够，是 LLM API 协议层的字段归属之争。要稳定不被盖掉，得把自研流程的优先级声明放到 API 顶层 system 字段里，再加上多层兜底。 最小可行方案，按优先级从上到下： 优先级 改动 协议层位置 投入 跨项目生效 抗 sandbox 重建 P0 编辑 ~/.config/opencode/AGENTS.md 顶部加「流程优先级声明」 system 顶层字段 5 分钟 ✅ ❌（需 ...

从一个根本矛盾说起 广告投放线上排查最常遇到的两大主诉是超成本和不起量，其余几乎所有"异常"——炸量、空耗、爆量、成本飘移、学习期失败、跑偏人群、素材疲劳、赔付不触发、一键起量反噬——都可以还原为同一个矛盾：广告主设置的出价与目标，和系统依据 eCPM 排序后实际选中的流量，出现了不可接受的偏差。 这份偏差的来源在 OCPX 系统里只有三条： 预估模型偏差：pCTR、pCVR 给出的不是真实概率，而是预估概率，带有固有误差 竞价排序偏差：同一广告位上，系统依据 eCPM = pCTR × pCVR × bid × 1000 排序挑选广告，任何一项输入失真都会让选中的流量向低质或高成本方向漂移 结算与归因偏差：扣费口径、转化回传、归因窗口、赔付阈值之间的任何错位，都会让广告主"账面看到的数据"和"系统里发生的事"对不上 上一篇《CPX / OCPX / eCPM：广告计费家族的演进版图》讲的是这套机制正常工作时怎么在广告主、媒体、系统三方之间分配风险。本篇的对象是反面：这套机制出问题时，会以哪些名字、哪些症状出现在工单...

高并发系统里最容易踩的坑之一，是在缓存初始化这条路径上为了"正确"而铺了一条会把整个服务排队卡死的路。正确性依赖事务，但事务如果选错了粒度和语义，就会把本应"偶发、短促"的初始化代价，传染给每一次取数调用。 下文以一个真实的序列号发号服务（odd/even 双主 + epoch 换届）为案例，梳理"高并发缓存初始化用短事务避免排队"这条设计模式，并把同一套系统里配套的几条高性能模式一并列出。 案例背景：发号服务的 epoch 缓存 系统结构简单地说是四层：allocator（号段分配）→ codec（编码）→ parser（解析）→ placement（下游落库定位）。发号主链路长这样： 12345allocate(seqKey, count) └─ ensureActiveEpoch(seqKey, days) // 读最新 ACTIVE epoch，若无则懒初始化 └─ (缺失时) EpochManager.rotateEpoch // 换届事务：多语句长事务，100~500ms └─ p...

全景金字塔 广告行业所有 CP* 和 oCP* 术语摆在一起，只做一件事：回答「广告主每一块钱应该在什么触发条件下花出去」这一个问题。不同缩写对应不同的触发条件（展示、点击、注册、下单、安装、停留），触发条件越靠近真实交易，媒体承担的风险越大、单价越高。前缀 o-（Optimized）是在原有计费条款之上套一层由机器学习驱动的智能出价，让系统替广告主去挑"最可能转化"的流量。而 eCPM 既不是计费方式，也不是出价方式，它是在广告系统排序那一刻，把所有出价方式折算回同一个量纲（每千次曝光的期望收入）的通用货币。公式 eCPM = pCTR × pCVR × bid × 1000 是今天所有主流广告拍卖的共同底层。 这一家族要解决的根本矛盾只有一个：广告主想按真实效果付费以锁定 ROI，媒体想按可控的曝光供给收费以锁定收入，两边都不愿意单独承担数据噪声、作弊和归因延迟带来的不确定性。广告计费从 1990 年代的 GD 合约一路演进到今天的 OCPX 自动出价，本质是在一次又一次地重新分配这份不确定性：谁承担风险、谁掌握数据、谁负责校准、谁来兜底。 本文做三件事。...