从一次性提示到工程化能力:Agent 上下文正在被重写 过去一年,围绕 Claude Code 的讨论几乎沿着同一条曲线展开:先是把它当作一个"会写代码的聊天框",然后开始用各类 CLAUDE.md、MCP server、子代理流程把上下文工程化。2026 年下半年,这条曲线出现了一个明显的拐点 —— 上下文工程( context engineering )从"模型怎么推理"被推向"工程团队怎么交
从一次性提示到工程化能力:Agent 上下文正在被重写
过去一年,围绕 Claude Code 的讨论几乎沿着同一条曲线展开:先是把它当作一个"会写代码的聊天框",然后开始用各类 CLAUDE.md、MCP server、子代理流程把上下文工程化。2026 年下半年,这条曲线出现了一个明显的拐点 —— 上下文工程( context engineering )从"模型怎么推理"被推向"工程团队怎么交付"的位置。
两条独立的产品线在 30 天内相继落地,从不同角度印证了这一趋势:NeoLab 把他们在生产项目里磨了一年的 Claude Code 技能集合开源为 Context Engineering Kit,提出了基于 agentskills.io 协议的模块化方案;YC S26 批次中的 OneCLI v2 则选择了一条完全不同的路径 —— 不去优化 prompt,而是把"agent 该如何在团队里被托管"做成了一套完整工程基线。这两个项目表面上回答的问题不同,但它们共同指向同一个结论:Agent 的下一步,不在模型里,在协议层和 harness 层。
两套独立方案:Context Engineering Kit 与 OneCLI
Context Engineering Kit(CEK) 由 NeoLab 团队维护,被收录进 Awesome Claude Code 列表,目前最新版本是 v3.1.0。它定位为"高级上下文工程技术与模式"的集合,核心理念是用尽量小的 token 占用换取更高的输出质量。和一次性的 prompt 不同,CEK 把 prompt 拆成可插拔的 plugin( reflexion、sadd、sdd、review、tdd、ddd、fpf、kaizen 等十几个),每个 plugin 各自加载独立的 agents、commands 和 skills,互不重叠。它的硬约束是"按需加载":不安装的 plugin,它的指令不会进入上下文;只有触发对应命令时,对应的 skills 才会被注入。
OneCLI v2 是 2026 年 8 月发布的开源团队 agent 平台,YC S26 批次项目。它解决的命题是:如果一名员工的 agent 要真的承担工作负载(发邮件、改 Linear 工单、清理 S3 桶、跑 CI),谁来托管它?谁来管它的凭据?谁来审批它的高风险动作?OneCLI 的回答是:每个人有自己的 agent,运行在自己隔离的沙箱里,所有对外请求必须经过一个 Rust 写的网关,凭据由网关注入而不是交给 agent,所有高敏操作都需要人工在对话里点确认。
CEK 关心的是"agent 怎么把事做对",OneCLI 关心的是"agent 怎么被安全地部署给整个团队"。把它们放在一起看,正好覆盖了企业级 Agent Harness 的两个最容易被忽视的工程基线:技能层的上下文协议,以及执行层的运行时边界。
Skills 协议层:为什么一个 open standard 比一个好 prompt 更重要
在 Claude Code 早期使用方式里,"如何写一段好 prompt"几乎是唯一被讨论的话题。但随着 agentskills.io 规范在 2026 年逐步被多个生态(Claude Code、OpenCode、Cursor、Antigravity、Gemini CLI)接受,讨论焦点开始往协议层转移:skill 不再是 prompt 片段,而是一个有标准目录结构、有 schema 约束、有发现机制的可分发单元。
CEK 是首批完整采用这套规范的实现之一。它的 plugin 目录遵循统一结构,每个 skill 自带 frontmatter(描述、参数、触发条件),可以被宿主 agent 按需加载。仓库里能看到 actualize、brainstorm、cause-and-effect、critique、decay、do-and-judge、do-in-steps、do-in-parallel、do-competitively、apply-anthropic-skill-best-practices 等几十个 skill,每一个都对应一种特定的认知或工程动作(反思、竞争设计、并行实施、根因分析……)。这种设计的实质是:把"上下文里的内容"从一坨长 prompt 切分成可寻址、可重用、可版本化的能力单元。
这种切分带来的直接收益,是 token 效率的指数级改善。CEK 团队披露的对比表显示,同一个生产任务,在不引入任何工程化手段(one-shot prompt)时,1-3 个文件改动场景的"完全正确率"只有 60%-80%,而一旦叠加 /plan-task + 人工 review + /implement-task 的 SDD 流程,正确率可以拉到 99%,token 开销则从 0 涨到 5-35 倍。这个数字背后是一个并不浪漫的事实:模型质量与上下文长度呈负相关,只要 prompt 撑得足够长,模型就开始犯糊涂。
换句话说,skills 协议层真正的工程价值,是它把"给模型塞多少信息"这件事变成了可控的、可计量的、可优化的对象。你不再需要在"详尽 prompt"和"简洁 prompt"之间二选一 —— 你可以在恰当的时机,把恰当的 skill 拉进上下文。这是企业级 Agent Harness 的第一块基石。
从技能到执行:Reflexion / SADD / SDD 的递进
CEK 把工程化能力分成三层递进,这套递进本身就是企业落地时可以参考的成熟路径。
第一层:Reflexion(反馈循环)。这是最轻量的工程化干预,核心是 /reflect 命令:让 agent 在每次输出之后,基于 self-refinement 框架对自己的结果做一次复盘,识别遗漏的需求、可改进的地方、错误的假设。如果发现问题严重就当场修复,如果只是小问题就给出建议等待用户确认。再加一个 /memorize,把这次复盘里学到的教训沉淀到 CLAUDE.md,下次同类任务直接避开。这一层对应学术上的 Reflexion 论文(arXiv:2303.11366)和 Self-Refine 论文(arXiv:2303.17651),后者在七类任务上证明可以提升 8%-21% 的输出质量。
第二层:SADD(Subagent-Driven Development)。每个任务派一个全新的子 agent,任务之间互相隔离、互相做 code review。它的关键 skill 是 do-and-judge:主 agent 把任务派出去,judge 子 agent 验收结果,verdict 不通过就让主 agent 重做。这一层在 CEK 的统计里能把 4-10 个文件改动场景的正确率从 30%-50% 拉到 83%。它的代价是 token 开销 1.5-3 倍,但换来的是几乎不再因为上下文污染( context rot )而翻车。
第三层:SDD(Spec-Driven Development)。这是 CEK 当前最强的一层,基于 Arc42 规范和 LLM-as-Judge + Agent Swarm 模式。它的流程是 /brainstorm → /plan-task → /implement-task:先用 brainstorming skill 把需求和约束做一轮结构化展开,再用 /plan-task 让 planning agent 生成 spec(spec-driven 的核心),最后由 /implement-task 派实施 agent 严格按 spec 落地。中间任何一步偏离 spec,都会被 reviewer agent 通过 functional / OOP / DDD / SOLID 等规则拦下来。CEK 给出的数字是 20+ 文件改动场景的正确率从 1%-20% 拉到 95%,token 开销 5-35 倍。整套流程被官方称为 "development as compilation"。
这三层并不互斥,而是可以叠加。Reflexion 是底座(永远开着,反馈循环永远在跑),SADD 是中段(任务隔离 + 互相 review),SDD 是上限(规范先行 + 自动校验)。对一个企业而言,真正可行的方案不是一上来就上 SDD,而是先把 Reflexion 的反馈循环跑通,再用 SADD 解决上下文污染,等流程成熟后再上 SDD 解决"不同工程师写出来的代码架构不一致"这种规模化问题。
Agent Harness 的工程基线:从 OneCLI 看企业级落地
CEK 解决的是"agent 怎么把事做对",但企业真要把 agent 派给员工之前,还有另一组问题必须回答:谁托管 agent?凭据怎么管理?谁审批?怎么审计?OneCLI v2 给出的答案是当下最完整的一套企业级 Agent Harness 模板。
OneCLI 的核心抽象是 "an agent is a durable thing, not a single prompt"( agent 是一个持久化的实体,而不是一次性的提示)。每个 agent 在 OneCLI 里都拥有:一台隔离的计算机(sandbox + 文件系统 + shell)、一段持久的对话(可在 Web 仪表盘或 Slack 里继续)、一份平台托管的记忆、若干个团队共享的 skills、一个可调度的执行计划、以及它自己永远看不到的凭据。
这套抽象里的工程细节,直接定义了什么叫做"企业级 Agent Harness"。
运行时边界:sandbox + 出站网关
OneCLI 的沙箱管理器(sandbox supervisor)跑在每个 agent 的容器里,执行标准化的 harness 接口,使得 agent runtime 本身可以替换(今天可以是 Claude Code,明天可以是 Hermes、OpenClaw、NanoClaw)。所有 agent 真正发起的对外请求,都会先到一个用 Rust 写的网关,网关负责两件事:一是基于主机的 host/path 模式匹配,从 AES-256-GCM 加密的密钥库里取出对应凭据,作为 HTTP header 或 query 参数注入;二是执行团队策略,拦下任何不符合策略的请求。
这个网关同时也是 MITM 代理,因此连 HTTPS 请求里的 Authorization 头都能被替换或注入,而不需要 agent 进程直接持有任何 secret。凭据生命周期被压到"按需解密 + 即时注入 + 不落盘",agent 进程的内存里从头到尾没有出现过明文 secret。
凭据与权限:看不到的凭据,可审计的策略
OneCLI 的凭据管理走的是 Vault 风格:支持团队共享连接(LLM keys、服务账号等),但每个 agent 只能拿到你显式授权给它的那一份。Bitwarden / 1Password 用户还可以开启"按需注入",根本不把 secret 存到 OneCLI 服务端。授权粒度不是按 API 整体,而是按 host + path 模式 + HTTP 动词,这样即便 Gmail 这种读写共用同一 host 的接口,也能区分"读邮件"和"发邮件"。
这是一个比传统 RBAC 重要得多的设计差异。RBAC 默认假设调用方是受信任的人,但 agent 不是人 —— 它可能因为 prompt 注入、上下文污染、工具调用错误而做出人类员工永远不会做出的动作。把权限粒度压到 URL 级别,本质上是承认:"agent 不可信,但 agent 必须能干活",二者之间的张力只能靠细粒度策略来调和。
审批与人类回路:in-chat human-in-the-loop
OneCLI 把人类审批做到了对话里:对真正高风险的副作用(发邮件、删 Linear 工单、清空 S3 桶),agent 必须把动作草稿发给对应员工,在 Slack / 仪表盘里显式 await 确认,确认后才会真正执行。这个设计看似只是把传统 IT 审批流程搬到了 chat 里,但它解决了一个关键问题:agent 不能被"后台授权",任何副作用都必须有可追溯的人类签字。
对国内企业而言,这个机制在合规层面有直接对应物:等保 2.0 对关键操作(数据删除、对外发送、权限变更)都有"双人复核 + 操作留痕"要求。Agent Harness 要落地,必须把这套机制内嵌进架构,而不是指望靠人工 review prompt 输出。
团队化:每名员工自己的 agent
OneCLI 提供的不是"一个 agent 给所有人用",而是"每名员工一个自己的 agent",由公司 IdP 自动 provision,每个人的 agent 拥有独立的沙箱、独立的对接(独立的 Slack app、独立的仪表盘页面)、独立的记忆,但所有 agent 共享同一份团队策略。这套架构天然解决了"代理身份"、"代理归属"、"凭据隔离"三个企业级难题。
从单兵到企业:Harness 工程化的五个判断维度
把 CEK 和 OneCLI 放在一起,可以提炼出 Agent Harness 走向企业级时绕不开的五个判断维度。这五个维度,既适用于自研 harness 的团队,也适用于评估现成方案( OneCLI、qm、Munder Difflin、OneCLI 之外的 sandboxed 平台)的决策者。
一、技能分发协议:是否采用了开放协议( agentskills.io 或等价的 SKILL.md 规范 )?还是把 skill 锁在私有格式里?开放协议意味着你不会被某个 vendor 锁死,而且 skills 可以跨多个 agent runtime 共用。CEK 已经在 Claude Code、OpenCode、Cursor、Antigravity、Gemini CLI 五端通用,这是协议层带来的复利。
二、运行时隔离与凭据注入:agent 是否在独立沙箱里运行?是否所有对外请求都过网关?凭据是否对 agent 不可见?如果这三项里有任何一项答否,这套 harness 都不适合带团队 —— 单人玩可以容忍,一旦扩到多人多 agent,凭据泄露就是时间问题。
三、人类回路的颗粒度:人类审批是按"整体授权"还是按"单次副作用"颗粒度?前者意味着你信任 agent 不会犯错(实际不成立),后者才是工程意义上的 human-in-the-loop。OneCLI 的"在 chat 里 await 确认"是当前最自然的人类回路实现。
四、记忆与经验的持久化:agent 学到的东西是写到平台层( 可读、可审、可改 ),还是写到 prompt 文件( 不可见、不可审计)?CEK 的 /memorize 把反思沉淀到 CLAUDE.md,但 CLAUDE.md 是项目级文件,长期演化后容易变成无人维护的"记忆坟场"。OneCLI 把记忆放到平台层、任何人可读可改,是更可持续的设计。
五、可观测性:agent 的工具调用、策略拦截、人工审批是否全部有结构化日志?OneCLI 通过事件总线、Slack 集成和审计日志实现了完整 trace。CEK 这块还在靠用户自己 review CLAUDE.md 和 git log,差距明显。对企业级 harness 而言,没有可观测性,就没有排障能力,更没有合规审计。
企业落地的工程顺序:从 Reflexion 到 SDD,从单人 harness 到团队 harness
看完这两条独立的产品线之后,一套相对稳的落地顺序逐渐清晰。
第一阶段:先把技能层做厚。任何团队上手 Claude Code / OpenCode / Cursor,都应该先建立 CLAUDE.md + agentskills.io 规范,把团队的高频认知模式( 代码风格、领域约束、安全红线 )做成可复用的 skill,而不是写进每次 prompt。这一步几乎零成本,token 开销接近 0,但能给团队所有 agent 装上"团队共识"。
第二阶段:跑通 Reflexion 反馈循环。要求每名工程师每次完成任务后,显式触发 /reflect,把发现沉淀回 CLAUDE.md。这个习惯一旦形成,团队的 CLAUDE.md 会变成真正的活文档,而不是项目初期的应付检查。
第三阶段:上 SADD,解决上下文污染。当单个任务涉及超过 10 个文件改动时,one-shot 提示的正确率会跌到 5%-30%。这时候必须把任务拆给子 agent、judge 子 agent 互验。这一步的关键不是技术,是文化 —— 团队要接受"花 3 倍 token 换 80% 正确率"是值得的,而不是继续相信"模型能一次写对"。
第四阶段:上 SDD,统一架构语言。当团队规模超过 3-5 名工程师、每个人都在同时改同一套代码时,正确率问题就不再是单任务的,而是架构一致性、接口契约、领域边界的全局问题。此时需要 /plan-task 生成 spec、/implement-task 严格按 spec 落、reviewer agent 自动按 DDD / SOLID 规则拦截。这条路走通,代码评审的负担会大幅下降,新成员上手周期会显著缩短。
第五阶段:从单人 harness 升级到团队 harness。当 agent 开始替员工处理对外动作(发邮件、改工单、操作生产数据),运行时隔离、凭据注入、人类回路就变成硬性需求。这个阶段要么自研一套类 OneCLI 的网关 + sandbox,要么直接采用 OneCLI、qm、Munder Difflin 这类开源平台。决策的关键不是"用谁的",而是"必须有谁负责审批策略、谁负责凭据轮转、谁负责审计留痕"。
不是更聪明的模型,而是更结实的工程
CEK 和 OneCLI 在 2026 年 8 月-9 月相继落地,传递的不是"模型又变强了",而是"agent 已经被认真当作生产系统组件对待"。模型质量的天花板仍然存在,但企业能不能用好 agent,几乎完全取决于技能层和执行层的工程基线。
对中文技术社区而言,这两条产品线的真正意义是:它们把"上下文工程"和"agent harness"从模糊的 buzzword,变成了可下载、可阅读、可借鉴的具体实现。任何团队都可以从 NeoLabHQ/context-engineering-kit 仓库直接拿走 SDD 流程的设计理念,从 onecli/onecli 仓库直接看清团队级 harness 的运行时拓扑。这种开放,正是过去半年 AI 工程领域最值得记录的变化。
下一个拐点大概率会出现在"agent 之间的协议"层 —— 多个 agent 在同一个企业里互通、互审、互委托。如果 skills 协议已经标准化了,harness 接口也会走向标准化。等到那一天,"企业级 Agent Harness"会变成像今天的"CI/CD pipeline"一样普通的基础设施名词,而这正是所有正在认真做落地的团队,真正想要的终局。
