守株阁

生成时间：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 分钟 ✅ ❌（需 P...

从一个根本矛盾说起 广告投放线上排查最常遇到的两大主诉是超成本和不起量，其余几乎所有"异常"——炸量、空耗、爆量、成本飘移、学习期失败、跑偏人群、素材疲劳、赔付不触发、一键起量反噬——都可以还原为同一个矛盾：广告主设置的出价与目标，和系统依据 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 └─ pi...

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

引子：AGENTS.md 是什么 在仓库根目录放一个 Markdown 文件，告诉 AI Coding Agent 这个项目是什么、怎么构建、有哪些规矩。这个做法现在有了一个事实标准的名字——AGENTS.md。 它的角色是：README.md 给人类读者看，AGENTS.md 给 AI 读者看。前者聚焦快速开始与贡献指南，后者聚焦构建命令、编码约束、验证闭环、踩坑清单，覆盖任何会影响 Agent 产出正确性的上下文。 这个概念最初由 Anthropic 的 Claude Code 以 CLAUDE.md 形式普及。随后各家工具一度各走各路：Cursor 用 .cursorrules，Copilot 用 .github/copilot-instructions.md，Gemini CLI 用 GEMINI.md，Cline 用 .clinerules，Sourcegraph AMP 提议 AGENT.md（单数），OpenAI Codex 提议 AGENTS.md（复数）。最终以 OpenAI 的 AGENTS.md 胜出——AMP 主动把 agent.md 域名重定向到 age...

背景 2026年4月12日，匈牙利总理欧尔班在议会选举中败给了反对党Tisza党领袖Péter Magyar，结束了自2010年以来长达16年的执政。Magyar在新一届国会199席中斩获约135-138席，欧尔班当天承认败选。 这场选举超出了匈牙利一国的范畴。欧尔班长期以欧盟内部的"异类"自居，在移民、对俄制裁、对华关系、民主制度等议题上与布鲁塞尔屡屡冲突，同时与特朗普、内塔尼亚胡等全球右翼领导人建立了紧密个人纽带。他的下台，搅动了多方势力的神经，各方反应构成了观察当前国际格局的一面棱镜。 特朗普：从高调背书到冷淡切割 特朗普是欧尔班选前最重量级的外部背书人，整个背书行动分为四波推进： 2026年2月5-6日，特朗普首次在社交媒体上为欧尔班站台，称其为"真正强大有力的领导者（a truly strong and powerful Leader）"。3月23-24日，他在布达佩斯CPAC会议上发表视频讲话，当众确认背书。3月24日，又在Truth Social发表正式声明： “Election Day is Sunday, April ...

2026 年的 AI 智能体赛道已经走过了"谁能调用工具"的初赛阶段。Hermes Agent（Nous Research，150k stars）把封闭学习回路做成了开源 agent 的标志性功能；OpenClaw（Peter Steinberger，371k stars）用 20+ 消息平台网关拿到了当前最大的开源智能体用户基数；Claude Code（Anthropic，123k stars）以绑定自家模型的编程工具身份卡住了 IDE 赛道的头部位置；Crush（Charmbracelet，原 OpenCode 项目，24k stars）在模型无关的编程智能体方向建立了自己的生态位。 这几类方案在功能清单上有大量重叠——都能读写文件、执行命令、调用外部工具。但把视角从功能清单转向记忆架构，差异立刻变得不可调和：有的方案每次会话结束就失忆，有的靠用户手写配置文件维持上下文，有的让 agent 自己往磁盘上写经验。记忆设计的差异，不是一个功能维度上的强弱问题，而是一个根本性的产品定位分歧——它决定了这个 agent 在回答什么问题、服务什么场景、适合什么样的用...

很多看起来是「推理任务」的 LLM 工作，其实骨子里是搜索任务。问一份 10M token 的代码库里某个 bug 何时引入，问一份万字 PDF 的第 17 页和第 184 页的数字是否一致，问一段"最近三个月里所有和 Symphony 架构有关的 commit 和 blog"——这些题目的共同点是，答案必须从一个远超模型上下文窗口的语料里找出来，推理只是最后一公里，前面 99% 的距离是检索。 这篇文章围绕一个具体问题展开：当任务里藏着一个巨大的搜索子问题，当前 LLM 社区在「降低搜索成本」和「提高搜索精度」两条线上各自走到了哪一步？ 选取三个互相咬合的锚点：递归语言模型（Recursive Language Models, RLMs）、LLM Wiki 范式、以及 RAG 家族自身在 2024–2026 年的演进。三者并列，不是因为它们属于同一层，而是因为它们从三个不同的抽象层次攻击同一个搜索成本问题。 一张图先把坐标系摆好 一个 LLM 应用要处理超出单次上下文窗口的知识，历史上只有四条路： 参数化记忆：把知识预训练或微调进模型权重里。代价是更新贵、...

Superpowers 的 skill 体系：规则引擎、流程编排与纪律约束 Superpowers 是 Jesse Vincent 为各类 coding agent（Claude Code、Codex、Cursor、Gemini CLI 等）开发的一套方法论插件。它不是一组工具，也不是一个框架，而是一套通过 skill 组合出来的软件工程流程。 初次翻阅 README.md 会产生一个直觉：using-superpowers 看起来像所有 skill 的入口，是不是应该由它渐进式地调度其余 skill？深入读完全部 skill 文档后，这个直觉只说对了一半。 一个更根本的问题是：skill 到底是什么？从文件系统看，每个 skill 就是一个目录，目录里有一份 SKILL.md，最多再带几个 reference 或工具脚本。从运行时看，skill 是一段被 agent 按需加载进上下文的 prompt。但这都不是重点。Superpowers 在 AGENTS.md 里用了一个更准确的说法——skill 是 behavior-shaping content，它是写给 agent 看...

2026 年 3 月初，OpenAI 在 GitHub 上公开了 openai/symphony 仓库。这个仓库很容易被误读成「一份 SPEC 加一点示例代码」，因为根目录 README 把第一个选项写成了「让你喜欢的 coding agent 按 SPEC.md 自己实现一版」。但真正打开目录看，仓库里有三块东西：根目录的 SPEC.md，一套可以构建和运行的 elixir/ 参考实现，以及 .codex/、.github/media/ 这类围绕 Codex workflow、演示视频和工程素材组织起来的配套内容。elixir/README.md 里的启动命令不是伪代码，而是完整的本地构建链路：mise exec -- mix setup、mise exec -- mix build，最后用 ./bin/symphony ./WORKFLOW.md 启动服务 [Symphony Elixir README]。 所以 Symphony 首先不是一篇规范文档，而是一个被拆成两层发布的工程项目：SPEC.md 说明什么叫 Symphony，elixir/ 证明这套东西能作为一个长驻服...