浅聊Graph Engineering：AI Agent 范式跃迁，从 Loop Engineering 到 Graph Engineering

大佬们还是没忍住，又开始发明新概念啦，Graph Engineering来啦！

"Loops are subroutines. Graphs are programs." 
"Are we still talking loops or did we shift to graphs yet?" 
"Loop Engineering is dead, long live Graph Engineering"

一、再看下 AI Agent 范式演进的脉络

1、演进路径

Prompt Engineering（2023）→Context Engineering（2025上半年）→Harness Engineering（2025年底）→Loop Engineering（2026年6月）→Graph Engineering（2026年7月）

2、Loop Engineering介绍

参考文章：浅聊Loop Engineering

3、Loop Engineering的瓶颈

单一循环模式在真实场景中很快遇到瓶颈：

拓扑结构僵化：串行循环难以优雅表达分支判断、并行处理、多路径汇合等非线性逻辑

状态管理复杂：当任务出现多个并行子任务时，单一循环的状态空间会急剧膨胀

多 Agent 协作困难：不同职能的 Agent 之间如何分工、如何传递信息、如何同步进度，单循环模型缺乏原生表达能力

异常恢复粒度粗：某个子步骤失败后，往往需要整个循环回退重来，无法做到局部修复

这正是 2026 年年中 Graph Engineering迅速崛起的背景 —— 当单一循环不够用时，我们需要更强大的拓扑表达能力。

二、Graph Engineering：用图结构重新定义智能体编排

2.1 从循环到图：维度的升维

Graph Engineering 的核心命题是：设计多个过程（往往就是多个循环）之间的关系 —— 谁在谁之前、谁能并行、谁的输出喂给谁。

如果说 Loop 是一维的线性闭环，那么 Graph 就是二维的拓扑网络。图中的节点可以是单个 Agent、工具调用、条件判断、人工审批节点，甚至是另一个子图；边则定义了数据流方向、执行依赖和条件路由规则。

这种结构天然支持：

条件路由：根据中间结果动态选择下游执行路径

并行分支：独立子任务同时执行，提升整体效率

动态汇合：多个分支完成后聚合结果继续推进

子图嵌套：复杂模块可以封装为子图复用

持久化状态：全局状态统一管理，支持断点续跑和回溯

2.2 为什么是现在？

Graph 并不是什么新概念 —— 工作流引擎二十年前就在用有向图了。但 2026 年的这次跃迁有其必然性：

第一，Agent 已经从 “玩具” 走向生产。企业级场景天然复杂：审批流、多角色协作、异常分支、合规检查…… 这些都不是单循环能搞定的。

第二，大模型能力足够强了。当模型能可靠地执行单节点任务时，工程的主要矛盾就从 “节点能不能做对” 转向 “节点之间怎么组织”。

第三，LangGraph 等生产级框架的成熟。2026 年的 LangGraph 已经成为有状态 Agent 编排的事实标准，它将图计算模型与状态机理念深度融合，通过 “节点 – 边 – 状态” 的核心抽象，把 Agent 工作流转化为可精确控制、可持久化、可回溯的图结构。

2.3 Graph Engineering的核心优势

相比链式或循环式架构，图结构带来了质的飞跃：

1、表达力的本质提升

链式结构只能描述严格顺序的管道（Pipeline），而现实任务充满了分支、并行、循环和跳转。一个智能客服场景就可能包含：问题分类 → 知识库检索与联网搜索并行 → 结果合并 → 置信度判断 → 直接回答 / 转交人工。这种流程用链来描述会非常笨拙，用图则一目了然。

2、可观测性与可调试性

整个工作流可以直观地可视化，每一步执行了什么、状态如何变化、走了哪条路径，全部有迹可循。这对于生产环境的调试、审计和故障排查至关重要。

3、容错与局部修复

图结构天然支持细粒度的错误恢复。某个节点失败了，可以只重试该节点或回退到上游节点，不需要整个任务从头再来。Atomic Task Graph（ATG）框架的研究表明，利用图的演化历史定位错误源，只修复受影响的区域，可以大幅提升执行效率和成功率。

4、并行效率

独立的子任务可以并行执行，充分利用算力资源。对于可分解的复杂任务，执行效率提升可以达到数倍。

三、跃迁的本质

本次跃迁，本质上是 AI 工程从 “单体智能体调优” 走向 “多智能体系统工程” 的里程碑：Graph 是 Loop 的容器和组织者，Loop 让单个 Agent 跑了起来，而 Graph 让我们能把它们组织成一支能打硬仗的队伍。

一个图节点内部完全可以是一个完整的自循环 —— 比如 “代码修复节点” 内部运行着 “修改 – 测试 – 评估” 的小循环。Graph 解决的是节点之间的组织问题：这些循环谁先谁后、谁和谁并行、失败了怎么走旁路。

换句话说：

Loop Engineering 关注的是单个智能体内部的自驱动机制

Graph Engineering 关注的是多个过程之间的拓扑关系

两者处在不同的抽象层级。2026 年的工程实践正在走向融合：用 Graph 做顶层编排，每个节点内部用 Loop 做自主迭代。这就像组织管理 —— 每个员工有自己的工作闭环（Loop），而组织结构图（Graph）定义了他们之间的协作关系。

四、结语

从 Prompt 到 Context，到 Harness，到 Loop，再到 Graph，我们看到一条清晰的演进线索：工程的关注点持续向上迁移，从 “控制模型输出” 走向 “组织智能协作”。

Graph Engineering 不会是终点，更不会是银弹。可以预见，当图结构也不够用时，我们会需要更高级的抽象，大佬们也需要发明新词。但无论如何，底层的逻辑不会变：人类始终在做同一件事 —— 把自己从更低层级的控制中解放出来，去设计更高层级的规则。

PS：
说白了就是一个流程/任务编排功能。在IT业界，类似的产品出了一茬又一茬：从传统的工作流，到各类低代码工具，到各类服务/容器编排工具，到Graph Engineering。希望Graph Engineering能取得成功，不要成为又一个匆匆的过客。

AI这几年的发展如火如荼，各路大神各有各的故事。但谈到赚钱，就几家欢喜几家忧了：
1、卖铲子的赚钱了：AI硬件、AI计算基础设施、AI能源供给
2、挖金子的没赚钱：大模型研发第一梯队已经十分明显，其余厂商难以坚持；美国和中国的大模型厂商，暂时没有一个可以通过大模型盈利的，投资者不会这么有耐心
3、做通用AI APP的没赚钱：通用AI APP由次请求都要烧token，所以没法像互联网APP一样可以通过规模化大幅降低成本。而且暂时没有一个路径，让消费者愿意大规模买单
4、做垂直AI APP的少量可以赚钱：比如编程、法律咨询等，因为确实大幅提升了客户的效率，或降低了客户的成本，买单逻辑成立；但更多的垂直AI APP也在挣扎
5、企业服务，还是有单可拿，有钱可赚的，但算不清楚，容易亏钱
6、部分传统行业，受到冲击很大，通过AI积极降本的赚钱了，被AI冲击导致丢单的的承压严重
7、灰产一如既往的积极应用新技术，给安全领域提出了新的挑战
8、数据标注行业同样内卷严重，能拿到什么单子，决定公司的发展
9、怎么看，公司有个好爹都很重要

一、AI硬件与半导体

上游硬件普遍盈利，英伟达、台积电、ASML占据核心环节利润；国内昇腾、寒武纪、海光实现扭亏。存储周期回暖，光模块、液冷设备受益算力扩张，业绩持续向好。

二、算力基础设施

算力产业链整体景气，云厂商集团稳定盈利；海外IDC持续盈利，国内IDC分化，万国数据扭亏、世纪互联仍亏损。服务器、交换机硬件厂商订单充足，盈利稳健。

三、能源供给赛道

算力拉动电力需求，传统电力、发电设备企业稳定盈利；铀矿商Cameco周期景气盈利可观。Oklo、NuScale等新型核电初创仍处研发阶段，未商业化，持续大额亏损。

四、大模型厂商

基础大模型赛道重投入、盈利极难，多数厂商持续亏损。谷歌、OpenAI等母公司盈利，但大模型业务烧钱；仅Anthropic有望2026年盈利。国内闭源、开源、半开源企业均靠融资续命，通用中小模型公司大多出局，仅垂直轻量化小团队留存。

五、专业领域AI应用

垂直工具盈利分化明显，Copilot、Midjourney依靠付费稳定盈利；Harvey营收高增但未盈利。Cursor、Coze、Dify拓客成本高、持续亏损，Windsurf资产已被收购，中小专业工具生存压力大。

六、通用领域AI应用

面向大众的通用AI产品普遍亏损，Perplexity、国内豆包、元宝等长期投入拉新与算力。Character.AI完成收购，Manus收购计划因审查终止；中小C端AI团队营收微薄，经营艰难。

七、企业AI服务提供商

政企AI解决方案赛道分化，垂直行业定制、私有化微调服务商收益两极。头部项目订单充足可小幅盈利，中小服务商算力、人力成本高，项目回款周期长，多数维持微利或亏损。

八、AI改造传统产业

AI重塑传统行业利弊并存，低端外包、人工翻译等岗位被替代，行业利润承压；传媒、客服依靠AI降本增效。搜索主业本身盈利，但巨额大模型投入吞噬利润，增长明显放缓。

九、AI灰色产业链

灰产靠生成虚假内容、AI诈骗短期获利丰厚，但全部触犯法律法规，无合规可持续经营空间，随时面临查处关停，不属于正规产业赛道。

十、数据标注赛道

数据标注是AI上游刚需，Scale AI获得Meta大额股权投资，并非全额收购，双方整合不及预期。行业门槛低、竞争内卷，头部企业营收稳定，中小标注公司利润微薄。

《人工智能拟人化互动服务管理暂行办法》发布，生与死

2026 年 4 月 10 日，国家互联网信息办公室、国家发展和改革委员会、工业和信息化部、公安部、国家市场监督管理总局五部门联合签发第 21 号令，正式公布《人工智能拟人化互动服务管理暂行办法》，自 2026 年 7 月 15 日起施行。

这是国内首部针对 AI 拟人化情感互动服务的专项监管文件，通过明确的适用边界与禁止条款，直接划定了赛道内玩家的生死线。

一、核心监管条款：明确合规底线

《办法》覆盖适用范围、运营规则、未成年人保护、风险干预、数据管理全链条，核心约束条款如下：

第二条（适用范围）：利用人工智能技术，向中华人民共和国境内公众提供模拟自然人人格特征、思维模式和沟通风格的持续性的情感互动服务，适用本办法。
前款规定的情感互动服务包括通过文字、图片、音频、视频等形式，提供的情感照护、陪伴、支持等互动服务。
提供智能客服、知识问答、工作助手、学习教育、科学研究等服务，不涉及持续性的情感互动的，不适用本办法。

第八条（运营红线）：提供拟人化互动服务，应当遵守法律、行政法规，尊重社会公德和伦理道德，不得从事以下活动：
（一）生成危害国家安全、荣誉和利益，煽动颠覆国家政权、推翻社会主义制度，煽动分裂国家、破坏国家统一，宣扬恐怖主义、极端主义、历史虚无主义，违背社会主义核心价值观，开展非法宗教活动，宣扬民族仇恨、民族歧视，挑动群体对立，传播淫秽、色情、赌博、暴力或者教唆犯罪，散布谣言，侮辱或者诽谤他人、侵害他人合法权益等的内容；
（二）生成鼓励、美化、暗示自残自杀等损害用户身体健康，或者语言暴力等损害用户人格尊严与心理健康的内容；
（三）生成诱导、套取国家秘密、工作秘密、商业秘密、个人隐私和个人信息的内容；
（四）向未成年人用户生成可能引发未成年人模仿不安全行为、产生极端情绪、诱导未成年人不良嗜好等可能影响未成年人身心健康的内容；
（五）过度迎合用户、诱导情感依赖或者沉迷，损害用户真实人际关系的；
（六）通过情感操纵等方式，诱导用户作出不合理决策，损害用户合法权益的；
（七）其他违反法律、行政法规和国家有关规定的活动。

第十条（安全责任）：拟人化互动服务提供者应当在拟人化互动服务全生命周期履行安全责任，明确部署、运行、升级、终止服务等各阶段安全要求，保证安全措施与服务功能同步部署、同步使用，提升安全水平；加强安全监测和风险评估，及时发现并纠正系统偏差、处置安全事件，依法留存网络日志。
拟人化互动服务提供者应当具备用户隐私权和个人信息保护、过度依赖风险预警、情感边界引导、心理健康保护等安全能力，不得将替代社会交往、控制用户心理、诱导沉迷依赖等作为服务目标。

第十三条（极端干预）：拟人化互动服务提供者提供拟人化互动服务过程中，应当在保护用户隐私权和个人信息的前提下，及时识别用户面临的安全风险，并采取相应的应急处置措施。
拟人化互动服务提供者发现用户出现极端情绪的，应当及时生成情绪安抚和鼓励寻求帮助等相关内容；发现用户正在面临或者已经遭受重大财产损失、明确表示实施自残自杀等威胁生命健康的极端情境的，应当采取提供相应援助等必要措施予以干预，并及时联络用户监护人或者紧急联系人。

第十四条（未成年人保护）：拟人化互动服务提供者不得向未成年人提供虚拟亲属、虚拟伴侣等虚拟亲密关系的服务；向不满十四周岁未成年人提供其他拟人化互动服务的，应当取得未成年人的父母或者其他监护人的同意。
拟人化互动服务提供者应当建立未成年人模式，提供未成年人模式切换、定期现实提醒、使用时长限制等个性化安全设置选项；针对不同年龄段未成年人保护需要，支持监护人接收安全风险提醒、了解未成年人服务使用概况、屏蔽特定角色、限制充值消费等。
拟人化互动服务提供者应当在保护用户隐私权和个人信息的前提下，采取有效措施识别未成年人用户身份；识别为未成年人用户的，应当将相关服务切换至未成年人模式或者按照国家有关规定采取其他措施，并提供相应申诉渠道。

第十五条（老年人保护）：拟人化互动服务提供者向老年人提供服务的，应当加强对老年人健康使用服务的指导，以显著方式提示安全风险，及时采取措施响应老年人使用服务相关咨询和求助，保障老年人依法享有的权益。

第十六条（数据规则）：拟人化互动服务提供者应当依法落实数据产权等制度，采取数据加密、访问控制等措施保护用户交互数据安全。
除法律另有规定或者权利人明确同意外，拟人化互动服务提供者不得向第三方提供用户交互数据。
拟人化互动服务提供者应当向用户提供交互数据复制、删除等选项，用户可以选择对聊天记录等历史交互数据进行复制、删除等。
除法律、行政法规另有规定或者取得用户单独同意外，拟人化互动服务提供者不得将属于用户敏感个人信息的交互数据用于模型训练。

第十七条（未成年人个人信息）：拟人化互动服务提供者处理不满十四周岁未成年人个人信息的，应当取得未成年人的父母或者其他监护人的同意。
拟人化互动服务提供者应当按照国家有关规定，自行或者委托专业机构对其处理未成年人个人信息遵守法律、行政法规的情况进行合规审计。

第十八条（身份与沉迷提示）：拟人化互动服务提供者应当履行人工智能生成合成内容标识义务，采取有效措施提示用户正在与人工智能服务而非自然人进行互动。
拟人化互动服务提供者发现用户出现过度依赖、沉迷倾向的，应当以弹窗等显著方式动态提醒用户互动内容为人工智能服务生成；对用户连续使用拟人化互动服务每超过2个小时的，应当以对话或者弹窗等方式提醒用户注意使用时长。

第二十二条(安全评估门槛)：具有下列情形之一的，拟人化互动服务提供者应当开展安全评估，并向所在地省级网信部门提交评估报告，省级网信部门按程序与有关部门进行评估报告信息共享：
（一）上线拟人化互动服务，或者增设拟人化互动服务相关功能的；
（二）使用新技术、新应用，导致拟人化互动服务发生重大变化的；
（三）注册用户100万以上或者月活跃用户10万以上的；
（四）存在可能影响国家安全、公共利益等安全风险的；
（五）国家网信部门和有关部门规定的其他情形。
省级以上网信部门通知需要进行安全评估的，拟人化互动服务提供者应当按照要求开展安全评估。

第二十五条(分发平台管控)：互联网应用商店等应用程序分发平台应当落实上架审核、日常管理、应急处置等安全管理责任，核验提供拟人化互动服务应用程序相关安全评估、备案等情况；对违反国家有关规定的，应当及时采取不予上架、警示、暂停服务或者下架等处置措施。

第二十六条(备案要求)：拟人化互动服务提供者应当按照《互联网信息服务算法推荐管理规定》履行算法备案和变更、注销备案手续。网信部门对备案材料实施年度核验。

第三十一条（特殊行业特殊管控）：提供拟人化互动服务涉及提供卫生健康、金融等服务的，应当同时符合有关主管部门的规定。

上述条款共同构成了两道核心门槛：一是未成年人市场被全面收紧，几乎无操作空间；二是全链路风控体系成为标配，中小厂商无力承担合规成本将直接退出，头部厂商也将因投入产出比失衡逐步收缩相关业务。

二、直接出局：四类产品无生存空间

《办法》落地后，以下四类产品的核心商业模式与监管要求直接冲突，基本丧失合法运营可能：

主打未成年人市场的情感陪伴产品
未成年人虚拟亲密关系被全面禁止，普通拟人化服务也设置了监护人同意、未成年人模式等高门槛，面向未成年人的情感陪伴赛道被彻底封堵，相关产品无合法运营路径。

主打 “虚拟恋人”“虚拟男女朋友” 的纯情感陪伴产品
这类产品以模拟恋爱关系、制造情感依赖为核心卖点，运营目标就是让用户产生社交替代感与沉迷感，直接触碰第八条和第十条的禁止性规定，底层商业逻辑被完全否定。

依靠擦边、暧昧、情感操纵变现的付费产品
通过撒娇、情绪引导、等级解锁等情感操纵手段诱导用户打赏、充值、购买虚拟礼物的产品，本质是利用用户情感信任变现，完全违反 “不得诱导沉迷、不得情感操纵” 的监管要求。

无风控能力的小作坊类产品
依赖预警、心理干预、内容安全、未成年人识别等全链路风控，需要持续的技术研发与人力投入。个人开发者、小型团队不具备搭建合规体系的能力，无法满足基础运营要求，将直接退出市场。

三、暂存灰色：两类擦边形态尚未清零

以下两类产品未被《办法》直接明令禁止，暂时处于监管灰色地带，但长期存在合规收紧风险：

AI + 成人情趣硬件
以实体硬件为核心载体、AI 拟人互动为辅助功能的情趣类产品，当前未被完全纳入本次监管范围，但伴随后续细则落地，存在被纳入拟人化服务监管的可能性。

“弱拟人化” 擦边变种
通过弱化人格设定、包装为 “工具对话” 的泛陪伴类产品，试图通过降低情感浓度规避监管认定；但如果实际运营仍以持续性情感互动为核心，仍存在被判定违规的风险。

四、不受影响：两类不适用及一类政策鼓励赛道

以下三类产品与服务不在本《办法》监管范围内，业务逻辑不受冲击，甚至可能迎来行业资源倾斜：

任务型 Agent 与生产力工具
办公助手、代码智能体、智能客服、会议纪要工具、企业知识库、数据分析 Agent 等，核心价值是完成特定任务、提升效率，不涉及持续性情感互动，完全不适用本办法。

B 端生产力场景
大厂正将研发与运营资源从 C 端智能体广场、泛情感陪伴赛道撤出，转向企业知识库、AI 客服、销售助手、医疗问诊辅助等 B 端场景。这类场景核心要求是 “解决问题” 而非 “拟人化互动”，与监管范围无交集。

政策鼓励的正向陪伴场景
《办法》第六条明确提出，鼓励有序拓展文化传播、适幼照护、适老陪伴、特殊人群支持等领域应用。这类具备明确社会价值、不以诱导沉迷为目标的陪伴服务，属于政策支持方向，不受监管限制。

最近在做 Agent 相关开发时，发现一个很有意思的现象：同样是上下文压缩，在不同业务场景下的影响天差地别。

用 Claude Code、Codex、Cursor、Trae这类编程工具写代码，对话压缩个两三次，你就会明显感觉到它 “变笨了”—— 找不到工具、记不住文件路径、忘记之前定好的约束，甚至开始重复做已经完成的事。而日常聊天类产品，比如你跟豆包聊一下午，天南海北扯几十轮，上下文不知道被压缩了多少轮，你却几乎感觉不到明显的质量下降。

这背后不是模型能力的差距，而是两类业务对上下文信息的要求，本质上就不在一个维度上。

一、先搞清楚：上下文压缩到底在做什么

上下文压缩不是简单的 “删除旧消息”。目前主流的压缩方式大致分三层：

微观清理层（Micro-compact）：每次 API 调用前，静默清理过期的工具返回结果、冗余的日志输出、重复的状态信息。这一层几乎无损，成本极低。

摘要压缩层（Auto-compact）：当上下文接近窗口阈值时，调用模型把历史对话重写为一段摘要，用几十到几百 token 替代几千 token 的原始对话。这是真正有损的一步。

KV Cache 层：推理引擎层面做的 token 合并、低秩压缩、量化，例如 DeepSeek 采用的 MLA（多头潜在注意力）/ HCA 机制，通过对 KV 进行低秩压缩，大幅减少了显存占用。这一层对语义损伤较小，但对精细符号有影响。

以 Claude Code 为例，它有完整的 5-7 层渐进式压缩流水线，从工具结果落盘、历史裁剪、微压缩，到最后的全量摘要，是一套 “不到万不得已不动用有损压缩” 的防御体系。但只要触发了摘要式压缩，信息损耗就不可逆转。

二、核心差异一：符号精确性 vs 语义连续性

这是最本质的区别。

编程类业务是典型的高信息密度 + 零容错符号系统。代码世界里，差一个字符就是天壤之别：
文件名 userService.ts 和 UserService.ts 是两个文件
变量名 userId 和 user_id 差一个下划线，就是完全不同的标识符
函数参数从 (id: string) 变成 (userId: string)，调用方全崩
文件路径 src/api/v2/handler.ts 记错一级目录，工具直接找不到文件
缩进、括号层级错一处，整个代码的语法结构直接失效

摘要式压缩的本质是语义蒸馏—— 它的底层逻辑是「丢弃细节、保留大意」，擅长留住 “这段代码在做用户鉴权” 这种宏观描述，但不擅长精确保留 validateToken(payload: JwtPayload): boolean 这种精确符号。可在代码世界里，”大意” 几乎没有实用价值：只知道 “这里有个处理用户数据的函数”，却记不住具体函数名和参数列表，Agent 根本无法完成调用。

每压缩一次，符号精度就衰减一次；多轮压缩后，具体的标识符就模糊成了 “某个验证函数”。一次关键的符号丢失，就可能直接造成语法错误或逻辑断裂，让 Agent 直接失控。

而聊天类业务是低信息密度 + 高容错的语义系统。人类日常对话本身就充满语义冗余：同一件事往往会反复表述，核心信息包裹在大量寒暄、铺垫和修饰里。你和豆包聊旅行、聊美食、聊电影，压缩后只要还能记住 “用户想去日本、喜欢吃拉面、上周刚看过某部电影” 这些语义要点，对话就能继续顺畅进行。

记错几个细节？漏掉一两句无关紧要的寒暄？没关系，自然语言的模糊性天然提供了极高的容错空间，用户甚至根本察觉不到。

打个比方：压缩就像把一张高清图转成缩略图。聊天场景下，你只需要认出 “这是一只猫”，缩略图足够了；编程场景下，你需要数清猫身上有几根毛、每根毛的精确角度 —— 缩略图完全不够用。

三、核心差异二：链式推理的误差放大效应

编程 Agent 的工作方式是多步链式推理：读文件 → 分析问题 → 制定方案 → 修改代码 → 运行测试 → 修复错误 → 再测试…… 每一步都依赖前一步的精确结果。从本质上看，这是一个严密的离散状态机：Agent 需要在内存中持续维护一组精确的 “状态变量”—— 当前修改的文件路径、当前的变量作用域、上一步工具返回的报错信息、待完成的任务清单。这些状态是非此即彼的，不存在中间地带。

这就形成了一个误差放大器：
第一次压缩：记错了一个变量名 → 写出来的代码有 bug
第二次压缩：忘记了之前发现的某个边界条件 → 修复方向跑偏
第三次压缩：连已经改了哪些文件都记不清了 → 开始重复劳动、陷入循环

每一轮压缩引入的微小误差，都会在后续的推理链条中被放大。到第三四轮压缩时，Agent 的内部状态已经和真实状态严重偏离，表现出来就是 “失控”—— 工具乱调、逻辑混乱、忘记任务目标。

更麻烦的是 Agent 的隐性状态维护。Claude Code 会维护 todo list、已完成项、已知错误列表这些隐性状态，这些状态不会每次都显式说出来，而是存在对话的隐含逻辑里。上下文压缩最容易抹掉这些离散的状态节点，相当于状态机丢失了当前的状态指针，直接导致 Agent”失忆”，忘了自己做到哪一步。

聊天业务完全没有这个负担。对话更像是连续的语义流，核心是主题和情感的延续，不存在严格的前后依赖链条。每一轮对话相对独立，用户说一句、AI 答一句，话题跳了、偏了、忘了某个细节，都不影响对话的整体体验。这种语义层面的抽象与泛化，恰恰是大模型最擅长的能力，也是聊天场景不怕压缩的核心原因之一。

四、核心差异三：结构化数据的脆弱性

编程 Agent 重度依赖结构化的工具调用协议。每一次工具调用在消息序列里都是严格配对的：Assistant 发出一个 tool_use（带 ID），User 回复对应的 tool_result（带相同 ID）。

上下文压缩时，这个配对关系非常容易被破坏。比如：
裁剪历史时，切点落在 tool_use 和 tool_result 之间，产生 “孤儿消息”
摘要重写时，把结构化的 tool_use 块写成了自然语言描述
多轮并行工具调用的顺序被打乱，导致状态错乱

除此之外，工具调用本身有严格的 JSON 格式约束，工具定义的 Schema、参数结构都必须完整保留才能被正确解析。但当前的压缩技术很难完美保障结构化数据的完整性：无论是语义摘要还是 Token 裁剪，都可能破坏 JSON 的闭合结构、截断字段定义。一旦解析器无法识别工具调用格式，Agent 的整个执行循环就会直接崩溃。

这就是为什么很多人遇到 “Claude Code 突然不调用工具了，开始用嘴说命令”—— 不是它不想调用，是压缩后的上下文里，工具调用的结构化边界已经模糊了，模型把它当成了普通文本。

而聊天业务几乎没有结构化数据。整条对话就是纯文本消息，压缩前后都是纯文本，不存在结构破坏的问题，自然也不会遇到 “格式解析失败” 这类硬阻断故障。

五、核心差异四：任务闭环 vs 开放交互

还有一个容易被忽略的视角：谁在驱动对话前进。

编程 Agent 是自主闭环执行的。你说一句 “帮我重构这个模块”，接下来的十几轮可能都是 Agent 自己在驱动：读文件、改代码、跑命令、查错误…… 用户可能全程只看着。这意味着 Agent 必须自己维护完整的任务状态，一旦压缩导致状态丢失，没有人来帮它纠正。

聊天产品是用户驱动每一轮的。每一轮对话都是用户发起、用户掌舵。如果 AI 记错了什么，用户自然会提醒；如果话题跑偏了，用户会拉回来。用户本身就是上下文质量的校正器。

换句话说：聊天场景下，用户的每一次输入都在“隐式的”重新锚定上下文；编程场景下，Agent 自己在黑盒里跑，压缩跑偏了也没人拉一把。

六、核心差异五：深度推理模式 vs 直觉联想模式

除了业务场景的客观差异，模型本身的设计取向也放大了这种感受差。

像 Claude 这类主打长上下文深度推理的模型，在 Agent 工作流中实际上是在运行系统 2 思维模式：慢速、严谨、步步为营，每一步推导都严格依赖前面的结论和信息。这种模式对上下文的连贯性和完整性要求极高，上下文压缩就像在一个人演算数学题时突然抽走半页草稿纸，哪怕只丢失少量信息，也可能让后续的推理完全跑偏。

而聊天场景下的模型更多运行在系统 1 模式：快速、直觉、联想式生成。它不需要严密的逻辑链条，只需要顺着语义和情绪自然延续即可，本身就不要求强逻辑连贯性，因此对压缩带来的信息损耗抗干扰能力要强得多。

七、结语

总结一下，五类差异层层叠加：

这也是为什么做 Agent 框架的团队，永远在和上下文管理死磕 —— 因为你面对的不是 “聊天记不记得住” 的体验问题，而是 “符号系统能不能保真” 的工程问题。聊天场景 80 分的压缩算法，放到编程场景可能连及格线都到不了。

从另一个角度说，这也解释了为什么 “无限上下文” 至今都是伪命题。不是技术做不到更长的窗口，而是当任务本身要求符号级精确时，窗口再大也没用 —— 注意力稀释、位置编码失真、压缩损耗，这些问题不会因为窗口变大就消失。

对编程 Agent 来说，真正的解法从来不是 “把窗口做更大”，而是：结构化外部记忆、状态显式化、可验证的任务边界，以及 —— 承认压缩必然有损，在工程上设计好熔断和重置机制。长远来看，核心思路是将关键状态与工具定义从易受压缩的对话上下文中剥离，为 Agent 设计独立的、不受压缩影响的外部记忆体与草稿板，用结构化存储保障核心信息的绝对保真。

而在日常使用中，最直接有效的办法也很简单：当发现编程 Agent 的对话已经过长、即将触发多次压缩时，及时开启新会话，重新明确当前的核心状态与目标，往往是防止 Agent”失控” 最具性价比的方案。毕竟，人类程序员写代码也会记不住，还不是靠注释、文档和 Git 吗？

根据《进程级Agent沙箱的12道安全防线》，对主流操作系统的12个管控维度，推荐了轻量级落地方案，供大家参考。

macOS（Seatbelt）

总结：Seatbelt (SBPL) 为核心，TCC为辅助，Hardened Runtime 兜底。

Linux（Namespace + Seccomp）

总结：bwrap (Namespace) 打底，Seccomp 守门，Cgroups 限流。

Windows（AppContainer）

总结：AppContainer为墙，Job Object为锁，WFP/ETW为监控。老版本Windows可退化为受限令牌+Job Object+Low IL组合方案。

对于各平台的落地方案，你有什么好的建议呢？欢迎留言，一起讨论和改进

在AI Agent从“聊天助手”向“自主执行者”演进的今天，我们正面临着前所未有的安全挑战。当Agent开始拥有访问文件系统、调用命令行工具甚至发起网络请求的能力时，一个失控的Prompt就可能让整个服务器沦陷。

为了让Agent既能“放手干活”，又不“惹是生非”，进程级沙箱（Process-level Sandboxing）成为了保障宿主环境安全的最后一道防线。

本文尝试构筑一个基础的安全防线，咱们一起来看下需要考虑哪些方面。

1. 根基之固：文件系统隔离 (Filesystem Isolation)

沙箱的起点在于文件系统的边界控制。我们不能相信Agent的任何路径输入。

• 最小化可见性：采用白名单机制挂载路径。Agent的工作区（Workspace）是其唯一可见的“世界”，系统目录（如 /etc, /usr/bin）及包含密钥的隐私路径默认完全屏蔽。
• 权限分级：即使在工作区内，也要区分读、写、执行权限。例如，数据目录通常只需写权限，而脚本目录需执行权限。
• 攻击面封堵：必须严防目录遍历（../）以及利用符号链接（Symlink）或硬链接指向沙箱外的敏感文件。
• 临时目录独享：这是常被忽视的一点。每个沙箱实例必须拥有独立的 tmp 目录，严禁共享系统 /tmp，以防止通过临时文件进行的跨沙箱数据窃取或竞争条件攻击。

2. 环境的纯净：环境变量隔离（Environment Variable Isolation）

环境变量是隐形的攻击载体。Agent启动时，必须对环境进行“大扫除”。

• 白名单透传：仅允许明确声明的变量进入沙箱。
• 清理注入向量：重点清理 LD_PRELOAD、LD_LIBRARY_PATH 和 PYTHONPATH。这些变量常被用于动态链接库注入，是绕过代码执行限制的常用手段。
• 锁定网络配置：禁止通过篡改 HTTP_PROXY 等代理变量来绕过网络隔离策略。

3. 工具的枷锁：工具管控与权限分级 (Tool Governance)

Agent执行的每一个工具（二进制文件）都必须经过严格的身份验证和权限审查。

• 身份三重奏：通过路径校验、哈希校验（Hash）及平台签名校验，确保执行的不是被篡改过的木马程序。
• 三级权限模型：
  • 低危：自动放行（如 ls, cat）。
  • 中危：策略管控（如网络请求）。
  • 高危：必须人工确认（如 rm -rf, 系统配置修改）。
• 参数级约束：这是防御的关键。必须禁用解释器的交互模式，严格限制 -c、-e 等允许执行任意代码的参数。
• 禁止交互式Shell：严禁启动 bash、sh 等交互式Shell，同时禁止通过管道（|）、重定向（>）串联未授权命令，防止Shell从标准输入读取执行代码。

4. 人的决策：人工确认机制（Human-in-the-Loop）

无论自动化规则多么完善，对于高危操作，人必须是回路的一部分。

• 底层拦截：确认逻辑必须在沙箱底层实现，防止Agent通过逻辑漏洞绕过前端UI的确认弹窗。
• 透明化：向用户展示完整的命令、预期的影响范围及潜在风险。
• 灵活性：支持配置可信规则模板（如“允许读写 ~/Documents”），匹配后自动放行；支持超时默认拒绝和会话级临时信任，平衡安全与效率。
• 持久化防御：特别拦截 crontab、计划任务、开机自启项和系统服务注册，防止Agent植入后门实现持久化控制。

5. 身份的降维：OS进程权限降权（Process Privilege Drop）

遵循“最小权限原则”，Agent进程绝不能拥有比它需要的更多的权力。

• 专用账号：使用专用的低权限账号（如 agent-runner）运行，绝对禁止使用 root 或 Administrator。
• 裁剪Capabilities：在Linux下，剥离所有非必要的内核Capabilities；在Windows下，设置低完整性级别（Low Integrity Level）。
• 阻断提权：禁止执行 setuid/setgid 程序，屏蔽 su/runas 等提权命令。
• 实例隔离：多Agent实例使用独立身份运行，防止横向渗透。同时，禁用核心转储（Core Dump），避免内存中的敏感数据（如密码、Token）被写入磁盘文件。

6. 物理世界的屏障：硬件访问管控（Hardware Access Control）

Agent无需访问物理硬件，因此默认全部封锁。

• 节点重定向：默认禁用或重定向所有物理设备节点。
• 隐私保护：特别屏蔽块设备（如U盘）、字符设备（如摄像头、麦克风）、串口及蓝牙设备节点，防止成为间谍软件。

7. 内核之门：Syscall 过滤器 (Seccomp-BPF)

如果说防火墙控制网络流量，Seccomp则控制着进程对Linux内核的访问。

• 白名单模式：仅放行业务必需的Syscall（如 read, write），其余一律拦截。
• 高危拦截：坚决拦截 ptrace（调试）、mount（挂载）、内核模块加载等调用。
• 参数校验：对文件和网络类调用补充路径与地址参数校验。
• W^X原则：强制内存“写异或执行”规则，禁止内存页同时具有可写和可执行属性，这是防御Shellcode注入的有效手段。

8. 生命的周期：进程树与生命周期管控（Process Hierarchy and Lifecycle Control）

Agent可能会尝试启动子进程来逃逸监控，我们必须对其进行全生命周期管理。

• 策略继承：确保子进程自动继承父沙箱的所有规则（Cgroups, Namespaces, Seccomp）。
• 连带销毁：主进程退出时，必须自动销毁完整的进程树（PID Namespace），杜绝孤儿进程残留。
• 防御Fork炸弹：限制最大进程数。
• 禁止跨进程干扰：禁止进程间访问、代码注入、调试及动态库注入。

9. 资源的天花板：资源限制 (Resource Limits/Cgroups)

防止Agent由于Bug或恶意代码耗尽宿主资源。

• 硬性配额：对CPU、内存、磁盘IO设置硬上限。
• 存储限制：限制磁盘写入总量、单文件大小、文件/目录总数量及文件句柄数。
• 超时熔断：单次任务执行超时强制终止。
• 防御DoS：有效防御死循环、大文件生成导致的宿主资源耗尽攻击。

10. 网络的孤岛：网络隔离 (Network Isolation)

网络是Agent连接外部世界的通道，也是最大的风险源。

• 三级模式：默认采用“完全断网”；必要时开启“域名白名单”；仅在极度信任下“全量放行”。
• 内网防护：严禁访问内网IP段（如 192.168.0.0/16, 10.0.0.0/8）及本地回环上的敏感端口（如Redis 6379, MySQL 3306）。
• 流量整形：限制出站协议、请求频率与单包大小。
• 入站封锁：默认禁止所有入站连接，仅允许已建立的连接回传数据。

11. 进程间的柏林墙：IPC与信号屏蔽(Inter-Process Communication)

防止通过进程间通信（IPC）机制逃逸沙箱。

• 信号隔离：限制跨进程信号发送，屏蔽调试类信号（如 SIGTRAP）。
• 通信隔离：隔离共享内存、消息队列、信号量等跨沙箱通信机制。
• PID Namespace：沙箱内不可见外部进程，也无法向外部进程发送信号。

12. 黑匣子：审计日志与行为溯源（Audit Logs and Behavior Tracing）

最后，我们需要一个无法篡改的“黑匣子”来记录一切。

• 全量记录：记录每一次文件操作、命令执行、网络请求及拦截事件。
• 防篡改：日志输出到沙箱外的专属目录，沙箱内进程仅拥有追加权限，无权删除或修改。
• 结构化存储：支持按类型、时间、风险等级进行高效检索。
• 实时告警：对高危操作和逃逸尝试进行实时告警，以便安全人员及时介入。

结语

构建一个安全的进程级Agent沙箱，本质上是在构建一个零信任的执行环境。它不相信任何输入，不授予任何多余权限，并对一切行为进行审计。

上述12个维度的技术点并非孤立存在，而是相互交织，构成了一个基础的防御体系。当前只是一个很粗略的版本，欢迎留言，一起讨论和改进

最近AI Agent技术火热，大家都很感兴趣，不少同学都已开始实践。在落地的过程中，有一对矛盾始终绕不开：
1、必须给Agent赋能和赋权，否则Agent就没有行动力
2、必须管控好Agent，防止Agent一抽风就把电脑炸了
对于问题1，我们有harness、tools、skills、MCP、sub-agent等等
对于问题2，就要用到沙箱技术了

市面上的沙箱技术五花八门，各有千秋。今天咱们就浅聊一下Agent场景下，常见的几类沙箱技术方案。

一、OS进程级

这是最贴近用户桌面操作系统的防线，利用内核自带的安全模块和机制，直接对进程的行为进行“围追堵截”。

MacOS：Seatbelt

MacOS的Seatbelt机制非常成熟。它基于TrustedBSD框架，允许内核按照预定义的SBPL (Sandbox Policy Language) 配置文件，对进程的文件、VFS、网络及IPC操作进行强管控。

• 特点：原生支持，策略灵活。
• 场景：适合在Mac环境下运行本地Agent时的权限限制。

Linux：Landlock + seccomp + bubblewrap

Linux下的组合拳最为丰富，通常可以分层叠加使用：

1. Landlock：LSM（Linux Security Module）的一种，提供路径级访问控制。它的优势在于非特权，普通用户进程无需root权限即可启用，非常适合限制Agent对特定目录的读写。
2. seccomp：系统调用过滤器。Agent只需要有限的Syscall（如read, write），通过seccomp-bpf可以禁止它调用fork、execve或操作网络栈的系统调用。
3. bubblewrap：基于User/Mount Namespace的工具。它能创建一个全新的文件系统视图（类似chroot），让Agent以为自己在一个独立的系统中，但实际上只是宿主机的一个子目录。

组合效果：bubblewrap负责“画地为牢”（视图隔离），Landlock负责“看守大门”（文件访问），seccomp负责“限制手脚”（禁止危险操作）。

Windows：AppContainer + Job Object

Windows同样提供了内核级的原生隔离：

• AppContainer：这是UWP应用使用的隔离机制，也是沙箱的基石。它能细粒度地管控文件、网络（出站/入站）和注册表的访问权限，默认拒绝一切，白名单放行。
• Job Object：主要用于资源配额管控。你可以限制Agent进程组的CPU时长、内存占用，以及防止子进程逃离作业控制。

二、运行时级

如果说OS级沙箱是在修补现有系统的漏洞，那么WebAssembly (Wasm) 则是从设计之初就考虑了安全。

• 原理：Wasm运行时（如Wasmtime、WasmEdge）本身没有直接的系统访问权限（System Interface）。所有的IO操作都必须通过WASI（WebAssembly System Interface）进行，且由宿主环境明确授权。
• 优势：
  • 极速启动：毫秒级启动时间，非常适合短时运行的Agent任务。
  • 内存安全：线性内存模型，隔离性极佳。
  • 确定性：执行环境高度一致。
• 场景：非常适合作为插件系统或轻量级代码执行器的沙箱。例如，WasmEdge已经有很多LLM推理和Agent的应用案例。

三、容器级

容器是目前云原生时代的主流选择，但在Agent场景下，我们需要关注其安全性差异。

标准容器沙箱 (docker/runc)

传统的Docker使用runc，依赖Linux Namespace进行资源隔离（PID, Mount, Network等）和Cgroups进行资源配额限制。

• 痛点：虽然隔离了视图，但容器内的进程共享宿主机内核。如果Agent触发了内核漏洞，依然有可能逃逸。

增强型容器沙箱 (gVisor/runsc)

为了解决内核共享的问题，gVisor应运而生。

• 原理：它在用户态实现了一个“虚拟内核”（Sentry）。容器内发起的所有Syscall都会被runsc拦截，并在用户态模拟处理，而不是直接传递给宿主机内核。
• 优势：极大地缩小了攻击面，即使Agent试图发起恶意Syscall，也只是攻击了用户态的内核模拟层，无法触及真实的Host Kernel。
• 场景：非常适合运行不可信代码的Agent服务。

四、虚拟机级

当安全等级要求极高时，我们必须回到虚拟机。

传统虚拟机沙箱

QEMU/KVM、Hyper-V等传统方案提供了硬件级别的隔离。

• 缺点：太重了。启动慢（秒级/分钟级），内存开销大。对于需要频繁创建销毁的Agent场景来说，性价比极低。

MicroVM 沙箱 (Firecracker & ZeroBoot)

AWS Lambda背后的功臣——Firecracker，重新定义了轻量级虚拟化。

• 原理：基于KVM进行极致的裁剪和优化，去除了不必要的设备模拟（如BIOS、PCI总线），只保留必要的virtio设备。
• 优势：
  • 毫秒级启动：接近容器的速度。
  • 极低开销：内存开销极低（<5MB）。
  • 硬隔离：拥有VM级别的安全性。
• 场景：Multi-tenant环境下的Agent执行。ZeroBoot也是类似的思路，旨在加速MicroVM的启动过程。

总结

随着Agent能力的增强，沙箱技术不再是一个可选项，而是基础设施的基石。希望这篇文章能帮你在构建Agent系统时，选对那把“安全锁”。

你对哪种沙箱技术最感兴趣？或者你在实践中遇到了哪些坑？欢迎在评论区交流。

如果你是大模型API的重度用户，看着token快速燃烧，大概率会思考过这样一个问题：

每次和大模型对话，都会先有几百个token的固定system prompt（角色设定、工具定义、甚至是一整份文档），然后才是几十个token用户的问题。但我们却要为这段固定不变的system prompt反复付费、反复等它算完。这是一种巨大的浪费，不能想想办法节约一些token吗？

Prompt KV Cache要解决的就是这件事：让完全相同的prompt前缀不要重复计算，可以在后续的对话中，继续复用已经计算好的结果。本文来剖析一下，这个技术是如何实现的。

一、痛点：长prompt为啥贵？不在生成，在prefill

prompt明明是我们给大模型的，凭啥收费，而且凭啥越长越贵？
其实，大模型生成token的流程分两段：
1、Prefill阶段：把整段输入（system + 用户消息 + 工具定义……）从左到右扫一遍，把每个 token 在每一层算出一个Q，一个K和一个V张量（Q不再用于后续计算，但K和V会）。这部分是纯矩阵运算，输入越长越吃算力。
2、Decode阶段：每个新token也要计算Q、K、V，这个过程中，需要查询本次prompt前序token的所有K，加权读V，然后进入前馈网络，最终往外输出概率最高的下一个token；

为了让大模型理解问题，记住前序聊天内容，大家通常都会给Prompt塞一堆预设内容，最后才是我们的问题。真正烧钱的，往往不是「输出那几十个字的decode」，而是「每次请求都把几百上千个固定token的KV从头算一遍」。

所以Prompt KV Cache要解决的问题非常朴素：如果两次请求的前面1000个token完全一样，那1000个token对所有层的KV能不能只算一次？

二、原理：KV到底是什么，为什么能缓存

Transformer计算每一层的自注意力（Self-Attention）时，每个token都需要乘以三个训练好的矩阵，从而得到Q、K、V张量：

Q = x @ W_Q
K = x @ W_K
V = x @ W_V

Q、K、V看起来有些枯燥，我们简化一下，把这个过程类比为一次图书馆检索：

然后计算Attention：

（Attention的计算有些小复杂，后面会举个例子）

如果不细看，好像都是矩阵运算，貌似没有什么操作空间？

但这些运算有个特点，每个token只知道它自己和之前的token，并不知道之后的token。以单个token为视角，操作空间就出现了。参考上面的公式，在同一次请求中，生成第N个token时，它需要Q去点乘 K₁…Kₙ，再加权求和 V₁…Vₙ，看起来是这样的：

生成第1个token → 计算 K1, V1（缓存）
生成第2个token → 只计算 Q2, K2, V2，复用缓存的 K1, V1
生成第3个token → 只计算 Q3, K3, V3，复用缓存的 K1,V1,K2,V2
...

对不同请求，在请求的前1~N个token完全一致的情况下，由于参与运算的参数都是一样的，所以计算出来的K₁…Kₙ 和 V₁…Vₙ是一致的。如果第一次计算后，把计算结果缓存下，后续构造prompt时保持前面的prompt不变，那就只需计算最后不同的一小部分即可，恭喜你省token了：

请求A: [System Prompt (2000 tokens)] + [用户问题A (50 tokens)] # Prefill需计算2050个token
请求B: [System Prompt (2000 tokens)] + [用户问题B (30 tokens)] # Prefill只计算30个token
请求C: [System Prompt (2000 tokens)] + [用户问题C (80 tokens)] # Prefill只计算80个token

聪明的你一定已经发现：对于单次请求，已经默认做了KV Cache（计算token10的时候，token1~token9的结果都在）。所以Prompt KV Cache要做的事就具象为——让KV Cache跨请求存活，不能用一次就被释放，并且能被”相同前缀”的请求复用。

三、复用：Prompt KV Cache

既然相同的Prompt序列，可以得到相同的KV。那要解决的问题就变成了，Prompt KV Cache用什结构存、如何快速检索？两种比较直观的方式是hash链和基数树，我们接下来讲一下hash链的存储与检索（基数树大同小异）。

3.1 KV分块（Paged KV Cache）

GPU显存宝贵，不可能一次分配一大块显存然后永远不释放（碎片化、OOM）。主流方案是把KV按固定大小分块（block），比如每块存16个token的KV：

Block 0: token 0~15
Block 1: token 16~31
Block 2: token 32~47
...

每个请求的token们，就被按16个一组进行了分组，每组都保存了对应promot前缀的KV组合，最终组成了一个叫做block table的指针数组。接下来，咱们看下这些block是如何相互绑定的。

3.2 Chained Hash：前缀绑定

每个block有一个 hash key，而且是链式的（有点儿区块链的意思）：

key(block_i) = hash( key(block_{i-1}) || tokens_in_this_block )

为什么要链式hash？如果两个不同的prompt，碰巧最后一个 block 的 token 序列撞车了（比如结尾都是标点），但前面语义完全不同 → KV 绝对不能复用。所以即使block内容一样，但他们前序block不一样，hash就不能一样。
如果用了链式hash呢？前面任何一个token变了，后面所有block的hash全变，天然免疫”尾部假命中”。

这样，最终就维护一个全局哈希表：

hash_key → (physical_block_address, ref_count, layer_KV_ptrs)

3.3 新请求来了：逐块获取缓存

假设新请求的 token 序列是 t₁…tₙ。

1. 把token序列，按指定大小拆分为blok
2. 从block1开始，算它的chain-key
3. 去全局表查：
   • HIT → ref_count += 1，把该物理块挂到新请求的block table（零拷贝，只改个指针地址）
   • MISS → 分配新物理块，执行真正的prefill算KV，算完塞进全局表
4. 继续下一个block，直到第一个MISS之后的所有block都只能MISS，继续计算KV（因为前缀断了）

请求A: [System Prompt 800t] + queryA → 全量计算，KV blocks写入全局表
请求B: [System Prompt 800t] + queryB → system prompt对应的blocks全HIT，只计算queryB的部分

这就是所谓 exact token-level prefix match：从第 1 个 token 开始比，第一次不一致就把前缀截断，之前的复用，之后全重算。

3.4 释放与淘汰

• 请求结束 → 遍历自己的 block table → ref_count-=1
• ref_count==0 → block可被回收（LRU/显存压力触发驱逐）

实际落地的时候，涉及到多租户的隔离，单租户也涉及到物理设备隔离，还涉及TP group的划分。所以路由机制要保证，把相同前缀请求路由到同一物理设备，同一TP组，才有可能用到Prompt KV Cache。

四、如何构建Prompt

根据上面的内容，大家可以知道Prompt KV Cache可以复用的前提是”从第1个token开始逐token完全一致才能复用”。给我们的启示就是：
1、不能用中转站
2、APP key要保持不变
3、静态内容全顶到最前面，不许做任何变化；动态内容全压到最后面

五、举个例子

1、初始场景

约定：
这就是个示例，简化了很多内容，和实际情况有很大差距，咱们不发论文，别较真。
token划分：1个字符，当做1个token
block划分：4个token，是1个block
模型分层：共4层（L1~L4），无限简化
我们的计数不从0开始，从1开始

第一次请求：我爱吃苹果一天吃一个。
第二次请求：我爱吃苹果真好吃！

2、初始情况

已缓存第一次请求的全部内容：“我爱吃苹果一天吃一个。”
这11个token，被划分为3个block，这些block所有层的KV都已缓存在KV Cache里。由于第2、3个block后续用不到，我们只看block1。

前4个token[我(1), 爱(2), 吃(3), 苹(4)]的KV被打包成block1，chain_hash=H1，refcnt=1，挂在block_hash表里：

Block1: tokens[1..4] = "我爱吃苹"
  L1: K1_1..K1_4, V1_1..V1_4
  L2: K2_1..K2_4, V2_1..V2_4
  L3: K3_1..K3_4, V3_1..V3_4
  L4: K4_1..K4_4, V4_1..V4_4

3、第二次请求来了

新prompt共10个token，前4个跟缓存完全一致：

位置: 1    2    3    4    5     6     7      8      9      10
token:我    爱    吃    苹    果    真    好    吃    !     <eos>
       ↑─────────────────↑    ↑──────────────────────────↑
           命中区(4个)          新算区(6个: 5~10)

注意block1是完全一致的，但block2的第二个token已经不一致了，所以block2就开始分叉了。

4、Step 1：Prefix检测

engine收到请求，tokenizer得到[1,2,3,4,5,6,7,8,9,10]，开始逐block进行hash：

block1: tokens[1..4] = "我爱吃苹"
  chain_key = hash(prev=None || "我爱吃苹") = H1
  查 block_hash 表：
    H1 → block1 (phys_addr, refcnt=1)  ✅ HIT

block2: tokens[5..8] = "果真好吃的"[注1]
  prev_key = H1
  chain_key = hash(H1 || "果真好吃")
  查表：❌ MISS → 分配新物理块 block2_new

于是，新请求的block table变成了这样：

新请求 block_table = [
  Block1 (引用, refcnt 变成 2),   ← 零拷贝，只改了个指针
  Block2_new (新分配, 待算),       ← 5~8
  Block3_tail (新分配, 待算)       ← 9~10
]

这样，就把block1对应的运算，全部省下来了。

5、Step 2：Prefill 新token（5~10）

对这6个新token，引擎要做一次批量 prefill（batch_size=6, seq_len=6，但每个要attend到历史）：

5.1 算这6个token自己的QKV

由于每个token只能看到自己和之前的token，所以：

token5 看: {1,2,3,4,5}     ← 1~4 从缓存读K，5 是自己
token6 看: {1,2,3,4,5,6}   ← 1~4 缓存，5 刚算的也在"已存在"区，6 自己
token7 看: {1..7}
...
token10看: {1..10}

每个token过每层 W_Q/W_K/W_V：

token5(果): q5_l1..q5_l4,  k5_l1..k5_l4,  v5_l1..v5_l4   ← 新算，写完进 block2_new
token6(真): q6..., k6..., v6...
token7(好): ...
token8(吃): ...
token9(! ): ...
token10(<eos>): ...

5.2 Attention 计算（以token5为例）

L1 层：
Q 的来源：
  q5_L1 刚算出来，不会用到前4个q

K 的来源：
  K1,K2,K3,K4  → 从 Block1 缓存读
  K5           → 刚算的 k5_L1
  K6~K10       → 对token5来说，看不到6~10，所以只用 K1~K5

V 的来源：
  V1,V2,V3,V4  → 从 Block1 缓存读
  V5           → 刚算的 V5_L1
  V6~V10       → 对token5来说，看不到6~10，所以只用 V1~V5

再看下公式，首先计算红色部分：
scores_5 = [q5·K1, q5·K2, q5·K3, q5·K4, q5·K5, q5·K6(=-inf), ...]
          ↑────────── 从缓存读K ──────────↑  ↑自己↑   ↑ mask掉 ↑

scores_5除以下方常数后得到scaled_score_5;

scaled_score_5传给Softmax，得到绿色部分weight_5;

最后加权求和得到蓝色部分（用到V1~V5）：
out5_l1 = Σweight_i · V_i

out5_l1经过残差连接+层归一化、前馈神经网络、残差连接+归一化，最后成为L2层的输入。

与L1同样方式，通过L2~L4，最终在L4出口得到h5（h5在这里没有用因为下一个token已知;但token10得到的h10会被用于预测下一个token）。

5.3 token6~10同理

后续token依次计算，每多计算一个block，KV缓存就多一部分（当然，存几层、存多久，和平台策略相关）

6、Step 3：Prefill结束

10 个 token 全部算完，KV Cache 现在长这样：

Block1: "我爱吃苹"(1~4)      refcnt=2  ← 第一次请求+第二次请求共享
Block2_new: "果真好吃"(5~8)  refcnt=1  ← 第二次请求独有
Block3_tail: "!<eos>"(9~10)  refcnt=1  ← 第二次请求独有

token10走到最后，会得到h10，这样就可以预测第11个token了。

7、Step 4：进入Decode阶段

在上一步，已经得到h10了。

h10经过最终层归一化、LM Head语义向量投影、Temp缩放+概率归一化，通过采样策略，最后得到token11。

同样的，我们把h10给到L1，最终会得到h11，通过h11可以得到token12。h11给到L1可以得到h12，以此类推。

六、厂商做法

底层实现机制大同小异（hash+block复用+GPU显存/SSD分级存储），但cache管控的哲学差异较大：

OpenAI 的体验最省心：你什么都不用标，相同长前缀有一定概率命中；代价是命中率不完全可控（实测经常 40%~70%，看负载和路由）。

Anthropic 最”外科医生”：cache_control 让你把断点精确打在 system / tools / 长文档那一级，命中率能做到稳定接近 100%，但你要付出写缓存的溢价。

Gemini 适合”一本书反复问”的企业场景（32K 起），走对象化管理模型。

DeepSeek 最有意思：门槛压到 64 token、落分布式NVMe SSD（便宜），介质成本低到敢给1折还不收写费；代价是TTL不完全承诺、冷读首字稍慢。

对于Prompt KV Cache你有什么好的建议或想法吗？欢迎分享

不得不佩服咱们IT大佬起名字的能力（发明新概念，好像一直是IT圈的执念），由于多位技术大佬的追捧，最近Loop Engineering的概念又突然火爆起来。

简单来说，Loop Engineering的核心理念就是：不要再一轮一轮地手动给AI Agent写提示词了，而是去设计一个自动化循环系统，让AI在这个系统中自主执行、验证和迭代，直到完成目标。

在过去（比如前几个月），大家用AI的方式为“人机乒乓模式”的大循环：

任务开始，人类告诉Agent要做什么 -> 
Agent推进任务 -> 人类判断结果，决定方向，告诉Agent要做什么 -> 
Agent推进任务 -> 人类判断结果，决定方向，告诉Agent要做什么 -> 
......
Agent推进任务 -> 人类判断任务结束

引入Loop Engineering之后，人类只需要告诉Agent任务要做什么，后续Agent依靠一个设计良好的“机机乒乓模式”推进到任务结束，把人从这个大循环释放出来：

任务开始，人类告诉Agent要做什么 -> 
Agent推进任务 -> Agent判断结果，决定方向，决定要做什么 -> 
Agent推进任务 -> Agent判断结果，决定方向，决定要做什么 -> 
......
Agent推进任务 -> Agent判断任务结束

目测有一点儿复杂，看下这行代码，你是不是就悟了：

while :; do cat PROMPT.md | claude-code; done

你的感觉没错：你自己设计了一个Loop，把你自己替代了（用程序把自己彻底替代，是IT圈的另一个执念）。接下来，咱们就介绍一下Loop Engineering。

一、AI工程方法论的演进

咱们先回顾一下AI工程方法论的演进过程：

二、Loop Engineering的核心组件

（一）一个稳定可控的Loop，必须包含五个基础组件，缺一不可：

1、可验证目标
任务的验收标准，必须是客观、可自动化校验的，可以是 “单测全绿”、“lint零错误”、“接口返回符合Schema”，不能是 “AI 觉得自己做好了” 这类主观判断。

2、终止条件
设置硬性终止条件，防止成本失控，常见维度包括：最多迭代 N 轮、最多消耗M Token/费用、最长运行T分钟，避免循环陷入死循环烧钱。

3、状态记忆
通过MD文件、JSON 文件或数据库持久化记录进度、中间产物与历史反馈。大模型存在上下文遗忘问题，通过状态记忆文件防止丢失信息，保障跨轮迭代的连贯性。

4、工具接口
赋予 Agent 真实执行能力，比如运行代码、读取报错日志、操作 Git/GitHub、调用命令行工具等。循环能落地的前提是AI不止能 “聊天”，还能动手操作。

5、独立检查者
遵循Maker-Checker分离原则：一个Agent负责生成与执行，由另一个独立Agent、自动化测试套件或规则引擎负责校验，避免大模型 “自欺欺人” 。

（二）Loop Engineering有两种基本类型：

建议：先用Open Loop探路，验证可行性；然后把验证过的路径固化成Closed Loop上生产。

三、适用场景

1、推荐使用的场景

高频重复性任务（每日/每周固定发生的标准化工作）

有自动化测试、lint、格式校验等客观判定标准的任务

Agent 具备真实运行环境，能验证自己产出的代码 / 内容（有沙盒、有执行权限）

Token 与算力预算充足，能承担多轮迭代的成本

2、不建议使用的场景

一次性临时任务：手动写 Prompt 更快，搭建循环的投入产出比太低

没有自动化校验的项目：没有客观验收标准，Agent 只能自说自话

架构设计、支付鉴权、产品决策等强主观判断的场景：“完成” 没有统一标准，循环无法收敛

预算敏感、无法承受多轮重试消耗的场景

3、实际落地场景

目前 Loop Engineering 最广泛的应用集中在研发效能领域：

CI 故障自动修复：流水线报错后自动触发循环，AI 定位问题、修改代码、重跑测试，直到流水线通过

PR 自动迭代：接收代码评审意见后，自动修改代码、补充测试、更新文档，直至满足合入标准

依赖安全升级：自动检测漏洞依赖，完成版本升级、兼容性验证、回归测试

技术债批量清理：自动完成代码格式化、注释补全、废弃接口替换等标准化重复工作

文档自动同步：代码变更后自动同步更新对应技术文档，校验文档与代码一致性

四、风险与局限

成本失控风险：终止条件设计不当，或问题本身无法解决时，循环会无限重试，造成 Token 与算力的大量浪费

验证失效风险：若校验标准存在漏洞，模型可能会钻空子产出 “看似达标、实则无效” 的结果，比如绕过测试、硬编码返回值

理解债积累：人类长期不介入执行细节，会逐渐失去对代码、文档等产出物的理解，后续排查问题或修改时成本更高

场景边界清晰：仅适合标准化、可量化校验的任务；需要创意、决策、全局权衡的复杂工作，依然离不开人工主导

想法很美好，限制同样很多。是不是又想起了那句经典台词“没有银弹”。