AI编码效率翻倍，公司业务为啥没感觉？阿姆达尔定律揭露AI编程提效天花板

近期，大模型的爆发和AI编程工具的发展，实实在在降低了编码门槛，样板代码、接口实现、单元测试这类重复性工作，综合产出效率普遍能达到原来的 1.5~2 倍。但与此同时，另一个体感悖论也越来越突出 ——代码写得更快了，项目上线速度、公司整体交付效率，却完全没有出现同比例的提升，很多团队甚至感觉评审、测试环节反而更堵了。

这不是管理失当，也不是 AI 不够强。早在半个多世纪前，计算机科学家吉恩・阿姆达尔提出的一条经典定律，就精准预言了今天的局面。

一、阿姆达尔定律：局部提速永远不等于全局胜利

1967 年，IBM 科学家吉恩・阿姆达尔在研究并行计算性能时，提出了一个简洁却极其深刻的结论：一个系统的整体性能提升上限，永远由其中无法被优化的部分所决定。

它的数学表达式非常经典：

其中：

S 是系统整体的加速比，也就是总效率提升的倍数
p 是可被优化环节在总流程中的时间占比
n 是该环节获得的加速倍数

这条定律最反直觉的地方在于：哪怕你把某一个环节加速到无限快，整体效率也存在无法突破的天花板，这个天花板恰恰来自那些 “提速不了” 的部分。

举个最经典的例子：如果一个程序有 30% 的代码可以并行优化，剩下 70% 必须串行执行，那么哪怕你投入无限多的 CPU 核心，把并行部分的耗时压缩到趋近于 0，整个程序的运行速度最多也只能提升约 1.43 倍。剩下 70% 的串行逻辑，就是无法逾越的硬瓶颈。

这个规律不仅适用于芯片与程序，同样完全适用于企业的运转流程。

二、先看研发内部：编码效率翻倍，研发整体能快多少

我们先把范围限定在研发部门内部，看看 AI 编程的提效在研发全链路中会被稀释到什么程度。

一个完整的软件研发交付链路，从来不是只有 “写代码” 这一件事。我们把从需求到上线的完整周期拆解开来，大致可以分为以下环节：

我们用普遍认可的务实假设代入公式：编码环节效率真的提升 2 倍，可优化部分占比 30%。

结论非常直观：编码效率提升 2 倍，研发部门的整体交付效率大约只能提升 18%。

如果团队的需求更复杂、评审更严格、跨团队协作更多，编码占总周期的比例会进一步降低到 20%，那么整体提升会缩水到约 11%。

更值得关注的是极限天花板：就算未来 AI 进化到写代码完全不花时间，研发整体效率的上限也只有约 1.43 倍。只要需求澄清、架构设计、代码评审、质量把关这些环节还是原来的节奏，研发效率就永远不可能翻倍，更别说达到 2 倍以上。

三、放大到全公司：审批与业务流程才是真正的天花板

如果把视角再拉高一层，站在整个公司的运转效率来看，AI 编程的收益会被进一步稀释。

讨论公司级效率，真正有意义的指标是端到端价值交付周期—— 从业务部门产生一个想法、提交需求，到走完立项、审批、研发、验收、落地全流程，最终产生业务价值的完整耗时。它串联了业务、财务、合规、研发、运营等所有部门，也包含了各类审批、等待、对齐的隐性成本。

我们以流程完善的中大型企业为原型，把完整链路拆解为三大阶段共 10 个核心环节，逐一评估 AI 编程对它们的实际影响：

一个扎心的事实是：在整个公司的端到端周期里，真正能被 AI 编程显著加速的 “编码实现” 环节，仅占总周期的 15%。剩下 85% 的时间，分布在业务决策、行政审批、合规风控、验收落地、组织协作中，全都和 “写代码快不快” 没有直接关系。

我们代入扩展版阿姆达尔公式计算，可以得到两种典型企业场景下的真实收益：

场景一：中大型 / 强监管企业（重流程、多审批）

这类企业常见于医疗、金融、政务、大型制造行业，审批链条长、合规要求高、跨部门协作成本高。
按上述占比计算后，优化后的总周期约为原来的 87.6%，整体加速比约为 1.14，即全公司运转效率提升约 14%。

就算编码环节耗时趋近于零，整体效率的极限天花板也只有约 1.25 倍。换句话说，哪怕 AI 免费写完所有代码，只要公司的审批、决策、验收流程不变，整体效率最多提升 25%，永远不可能翻倍。

计算过程：

场景二：研发驱动型轻流程公司

如果是产品驱动的互联网科技公司，决策扁平、审批少、业务与研发高度对齐，研发环节占比会更高。调整参数后计算，整体效率提升约 20%，极限天花板约为 40%。这已经是非常理想的结果。

计算过程：

四、现实更骨感：三个吃掉效率的反作用

以上还只是理论上的乐观估算。真实落地中，有三个普遍存在的反作用，会进一步抵消 AI 编程带来的收益，甚至让整体效率不升反降。

1. 代码膨胀导致评审与测试拥堵

AI 让代码产出速度翻了 2 倍，但评审代码的人、做核心逻辑验证的人并没有同步增加。原来一天 5 个 PR 可以按时审完，现在一天产出 10 个 PR，代码评审队列直接拉长；测试用例可以批量生成，但核心场景的验证、业务逻辑一致性校验依然依赖人力，大量产出的代码卡在下游环节，形成库存。很多团队的体感是：代码写得快了，卡在 CR 和测试的时间反而更长了。

2. 需求变更泛滥，返工成本飙升

编码成本变低后，业务侧很容易产生 “先做出来看看” 的心态，频繁提出变更、反复调整方向。原本需要想清楚再开工的需求，变成了边做边改，大量 AI 生成的代码被推翻废弃。编码省下的时间，全被额外的返工成本吃掉了，这是组织层面最常见的 “效率陷阱”。

3. 技术债累积，透支长期效率

AI 生成的代码往往偏向 “快速可用”，在架构一致性、可维护性、可扩展性上容易打折扣。短期看交付速度上去了，但长期来看系统会越来越难修改，后续需求的开发效率会逐步下降，相当于用未来的效率换取了当下的速度。

把这三个因素纳入考量，很多重流程企业的实际效率提升往往只有 8%~12%，管理失当的团队甚至可能出现负收益。

五、真正的启示：别在编码上死磕，去优化真正的瓶颈

理解了阿姆达尔定律在企业运转中的映射，我们就能跳出 “AI 能不能提效 2 倍” 的无意义争论，得到三个更有价值的结论。

第一，别对 AI 编程的组织价值抱不切实际的期待。
AI 编程是强大的研发提效工具，但它不是解决公司效率问题的银弹。它优化的只是全链路中的一个局部环节，而且往往不是瓶颈环节。指望靠几款 AI 编码工具让公司整体效率翻倍，和指望换个更快的火花塞解决堵车问题一样荒谬。

第二，AI 真正的价值是释放人力去攻坚瓶颈。
编码效率提升 2 倍，不意味着可以裁掉一半的工程师。正确的打开方式是：把工程师从重复的编码劳动中解放出来，让他们把时间投入到真正决定交付速度的瓶颈上 —— 更前置地介入业务、减少无效需求、打磨系统架构、推动流程自动化、完善质量体系。把省下来的编码时间，拿去优化那 85% 的串行部分，整体效率才会真正上台阶。

第三，未来的效率竞争，拼的是全流程的 AI 渗透。
只在编码环节卷 AI，很快就会触碰到阿姆达尔天花板。真正能拉开差距的，是那些能把 AI 能力渗透到需求分析、方案设计、评审校验、测试验证、合规审核、流程审批全链路的团队。当每个环节都获得一定程度的加速，整体效率才会出现量级的跃迁。

六、结语

AI 编程带来的 2 倍效率是真实的，但它只发生在代码工程师的键盘上。而一家公司的运转效率，藏在会议室的决策里、层层审批的流程里、跨部门的协作里、业务落地的执行里。后者不进化，前者再快也只是徒劳。

局部工具再强大，也替代不了组织层面的进化。这大概就是所有技术工具都绕不开的终极宿命。

Agent购物带来新挑战：当决策入口与履约剥离，电商的底层逻辑正在被彻底改写

近期各大电商陆续开始提供AI购物功能，各大AI平台也开始提供比价甚至购物功能（国内生态比较封闭，第三方购物Agent反而是国外走到了前列）。当你对着 AI 助手说一句 “帮我选一款千元以内无线降噪半入耳耳机，明天能送到”，就能直接收到下单确认时，你可能没意识到：电商行业运行了二十年的商业规则，正在被悄然拆解。

Agentic Commerce（代理式电商）不是货架电商、兴趣电商之后的一次界面升级，它的真正冲击力，不在于 “大家以后都不打开 App 了”，而在于它把 “决策入口” 和 “履约 / 供应链” 两层彻底剥开了。AI Agent 作为新的中间层拿走了筛选与决策的权力，传统平台则逐步退化为供给与履约的后端服务商。短期看传统投流、直播不会被颠覆，但标品、复购品的营销效用会被显著削弱；中长期看，谁握有 “AI 愿意调用” 的供给与履约能力，谁就握有了新的行业议价权。

一、入口与履约的剥离：电商底层逻辑的断裂

Agent 购物的本质，是在消费者和零售商之间插入了一个全新的决策中间层 ——AI 代理自主完成参数读取、跨平台比价、自动下单全流程。摩根士丹利研报预测，到 2030 年 AI 购物代理可为美国电商市场带来最高 1150 亿美元的增量消费，基准情景下将占据 10% 的线上零售份额，乐观情景下可达 20%。但报告同时明确指出：拥有强大基础设施、独特库存的零售商（亚马逊、沃尔玛）将成为赢家，而依赖高抽成和搜索流量的平台则会面临直接挑战。

映射到国内市场，这种冲击体现在三个核心层面：

1. 流量分发权被重新分配，注意力广告根基动摇

过去二十年的电商是 “人找货” 的逻辑 —— 用户在搜索框输入关键词、在列表页筛选，平台通过控制这个入口向商家收取广告费。支撑这套模式的，是全球近 2000 亿美元规模的零售媒体广告市场，搜索排名、首页展位、信息流推广，本质都是向商家售卖用户的浏览注意力。

Agent 进来后，决策主体从人变成了 AI：AI 读取结构化参数和数据做决策，不会被主图噱头吸引，不会因排名靠前就优先选择。建立在 “吸引人类眼球” 基础上的零售媒体广告模式正在发生根本性变化，平台可能从用户交互的前台，退化为 Agent 调用的后端服务。

2. 广告竞价体系的底层逻辑被直接撼动

电商平台的核心利润来源 —— 直通车竞价排名、坑位费、流量广告，本质是 “注意力税”。而 Agent 是绝对理性的比价机器，会瞬间穿透营销包装，把流量导向极致性价比的标品，直接冲击平台赖以生存的广告竞价体系。

对于高度标准化的品类，这种冲击尤为显著：3C 家电、日用品、包装食品等参数清晰的商品，用户会直接委托 Agent 比价下单，不再手动浏览页面，对应的搜索广告、展示广告价值会持续缩水。

3. 履约壁垒反而被强化：平台不会消失，只会分化

一个关键的事实常常被忽略：Agent 能替你决策，但不能亲自把饭送到门口，不能凭空变出骑手和仓库库存。外卖表面是信息生意，本质是履约生意 —— 商户密度、骑手规模、实时调度系统、线下运营能力，这些 “物理世界的密度” 无法被大模型瞬间复制。

所以更准确的判断是：AI 抽走了前端的决策入口，但后端的履约能力反而会强化头部平台的壁垒。纯流量型平台会面临巨大的入口替代风险，而重资产、强履约的平台，反而会成为 AI 时代的基础设施。

4. 封闭生态的囚徒困境：“伪全网比价” 的现实尴尬

目前国内各家平台的 AI 购物，并没有实现真正的 “全网比价”。实测显示，千问优先推荐淘宝天猫商品、豆包定向引流抖音商城、京东 AI 购主推自营货品，本质都是 “套了大模型外壳的站内搜索”。

平台陷入了典型的囚徒困境：开放全量数据对消费者体验最好，但对自身流量护城河最致命；封闭生态则会消解 Agent 购物的核心价值。这种集体选择的 “围墙花园” 策略，也导致当前 AI 购物体验与用户预期落差巨大 —— 海外调研显示，近七成的用户在收到无关推荐后会直接放弃使用，转而回到传统搜索方式。

二、被高估的 “客观”：Agent 没有消灭偏见，只是换了一种偏见

很多人认为 Agent 购物至少比人类更客观 —— 它不会被直播逼单忽悠，不会被品牌故事洗脑，只会理性对比参数。这句话只对了一半：Agent 确实能过滤人类的情绪偏差，但它同时引入了全新的 AI 决策偏差，甚至在某些维度上比人类更容易被针对性操纵。

1. “去营销化” 的优势真实存在

在过滤情绪型、套路型营销上，Agent 的价值毋庸置疑：

• 它会直接跳过主图噱头、详情页情怀、限时焦虑营销，只提取核心参数、价格、履约、售后等结构化信息；

• 它能自动在同价位、同定位的商品池中做参数对齐，避免厂商 “田忌赛马” 式的错位宣传；

• 它可以在几秒内读完数千条评价，自动提取差评集中的共性问题，比人类手动翻页的效率与全面性高出数个量级。

对于高度标准化的标品，Agent 在排除情绪干扰、提升决策效率上的优势非常明显。

2. 纸面参数≠真实体验，注水空间依然存在

Agent 只能识别可量化的纸面指标，无法判断实际使用体验。厂商完全可以针对性 “优化参数”：手机标注支持 100W 快充但标配 67W 充电器，家电标注一级能效但日常工况耗电更高，护肤品标注成分浓度却不说明活性与吸收率。

对于服装、食品、家居等非标品，本身就没有统一的参数标准，Agent 只能依赖商家打标签和用户评价做判断，反而更容易被关键词堆砌的营销内容误导。

3. 销量与评价，反而成了 AI 时代的新型作弊工具

人类看评价能通过语气、配图、追评时间分辨刷评痕迹，而目前大多数购物 Agent 主要做语义关键词提取，对 “高质量刷评” 的识别能力远弱于人类。

市场上已经出现了专门面向 AI 的刷评服务：商家组织刷手刻意堆砌 AI 偏好的正面关键词，反而能提升商品在 AI 推荐中的权重。同理，销量、店铺评分都可以通过刷单拉高，AI 会把这些注水数据当成 “受欢迎” 的依据，进一步放大虚假优势。

4. 大模型自带偏见，营销从 “前台” 转到了 “后台”

Agent 的底层大模型在训练时已经吸收了全网的品牌公关稿、营销内容、媒体报道，品牌知名度与口碑沉淀会天然影响推荐优先级。过去厂商投广告是影响用户心智，现在做品牌公关、铺全网内容是影响大模型的认知，本质还是营销，只是受众从人变成了模型。

更直接的偏差来自平台立场：绝大多数平台自带的购物 Agent 都有利益倾向 —— 优先推荐自营商品、高佣金商品、合作品牌商品。这种商业排序下的推荐，本质是平台利益优先，而非客观最优。

三、传统营销的冲击：标品广告失效，内容与品牌价值重构

传统投流、广告、直播不会彻底消失，但会出现剧烈的场景分化：在标准品、复购品、价格敏感决策上效用显著下降；在非标品、内容触发、品牌建设上依然有不可替代的价值，但形态会持续进化。

1. 效用显著下滑的三类场景

• 标准品的比价广告：3C 家电、日用品、奶粉等参数清晰、可量化比较的品类，Agent 会直接按性价比排序，Banner 广告、直通车竞价排名的有效性会持续走低。

• 冲动消费触发：限时秒杀、“砍一刀” 这类依赖人性弱点的玩法，对 “最不冲动的决策者” Agent 几乎无效，对应的流量变现逻辑会逐步失灵。

• 短链路种草转化：传统的 “看笔记→被种草→直接下单” 链路会被截断 —— 用户让 Agent 买护肤品，它会去查成分、比价格、看差评，而不是被一篇素人笔记打动完成冲动消费。

2. 依然不可替代的价值阵地

• 品牌曝光与心智建设：直播间、达人种草、短视频内容在 “制造欲望” 这件事上仍然不可替代。用户依然需要内容来发现新品、建立审美、产生消费冲动，再由 Agent 完成后续的比价与下单。抖音这类兴趣电商平台，在这个环节依然拥有核心优势。

• 非标品与情感消费：服装、美妆、家居、文旅等需要 “逛” 和 “感知” 的品类，消费决策包含审美、情绪、体验属性，人类手动购物仍是主流，Agent 只能起到辅助作用。

• 商家侧 AI 提效工具：阿里妈妈 “AI 万相”、京东 “京小通”、AI 数字人直播等工具正在快速普及，推动AI能力从C端入口向B端运营提效延伸，这部分的营销预算反而在快速增长。投手的角色从 “执行者” 转向 “策略制定者 + AI 训练师”。

3. 营销的新战场：GEO 正在崛起

广告预算不会消失，只会从 “人眼曝光” 流向新的方向 ——GEO（Generative Engine Optimization，生成引擎优化，也被称为 AEO，AI 引擎优化），也就是学会 “取悦机器”，让 Agent 在回答时优先推荐自己。

商家的运营重心正在发生系统性转移：

• 从优化主图点击率，转向优化商品结构化参数，统一行业标准口径，方便 AI 提取识别；

• 从引导用户快速下单，转向引导真实用户留下 AI 偏好的评价关键词，提升商品在 AI 排序中的权重；

• 从投放平台流量广告，转向完善商品知识库，主动向大模型提供官方、准确的产品信息；

• 从打造短期爆款，转向沉淀品牌全网声量，强化大模型对品牌的正面认知。

厂商不再需要说服人类消费者，但需要说服 AI Agent。话术从 “打动用户” 变成了 “符合 AI 排序规则”，营销的底层逻辑没变，只是战场变了。

四、平台梯队重塑：谁在 Agent 时代掌握了新议价权

Agent 时代，电商平台的核心竞争力从 “流量运营能力” 转向了供给确定性、履约壁垒、数据结构化程度与自有 AI 入口闭环能力。国内平台已呈现清晰的梯队分化，不同模式的平台命运截然不同。

阿里 —— 全链路闭环暂时领先半个身位

千问 + 淘宝闪购 + 饿了么 + 支付宝的全链路组合，是当下国内最完整的 AI 购物生态。阿里投入数百名算法工程师，将淘宝二十年的电商能力转化为千问可调用的技能库，内测数据显示，“AI 店小蜜 + 人工” 的组合转化率已实现全天候超越纯人工客服。

但隐患也同样突出：淘天的收入核心是竞价排名，本质是纯粹的注意力税，而 Agent 冲击最直接的正是这块利润基本盘；且千问只能检索淘宝生态内商品，“伪开放” 的争议会影响长期用户信任。

京东 —— 模式最安全，但入口偏弱

京东是被 Agent 冲击最小的传统电商 —— 因为它的核心利润来自进销差价而非广告费，重资产的物流体系恰好是 Agent 最信任的参数：履约确定性。

目前京东 AI 超脑大模型已覆盖上千个核心业务场景，同时与腾讯元宝打通小程序生态，拿下了微信 AI 原生的对话流量，对 3C 家电等决策型长周期商品的转化尤其有利。“服务封装一次、多渠道输出” 的开放路线，正在成为它对抗流量焦虑的核心策略。

短板在于第三方商家丰富度不足，且 “自营 = 放心” 的品牌溢价会被逐步压薄 —— 当 Agent 能独立验证任何渠道的商品可靠性时，平台的品牌招牌溢价会持续收窄。

美团 —— 履约壁垒深厚，但前端入口被抽走

美团是被 Agent 重构最明显的超级平台，但不会被消灭。
它的护城河在物理世界：千万级商家网络、数百万骑手体系、毫秒级实时调度系统，这些都是 AI 无法瞬间复制的硬壁垒。但用户习惯 “用 AI 点外卖” 后，美团会从超级 App 退化为本地生活履约核心，失去前端定价权与流量溢价。

王兴提出的 “To A” 战略，自研 “小美” Agent 并与腾讯元宝深度合作，本质是试图成为 “所有 Agent 背后的履约管道”。但管道化的代价也很明显：参考高强度的线下运营属性，其估值逻辑可能从高增长互联网平台向稳健的零售/物流基础设施靠拢，市盈率中枢或将下移。

抖音

豆包是国内 C 端用户时长和流量最强的 AI 入口之一，“豆包帮你选 + 抖音电商内容种草” 的闭环是独特路径。但隐患在于，当前广告模型依赖 “打断 + 情绪触发”，这正是 Agent 最先接管的场景；且供应链与履约能力依然是短板。

拼多多

白牌、极致低价的货盘，跟 Agent 的比价优化目标天然契合，在价格敏感型需求中是天生赢家。但它的变现高度依赖广告，流量玩法高度依赖冲动消费，而 Agent 是 “最不冲动的顾客”，长期变现逻辑承压。

小红书

核心价值是 “种草”，用内容制造欲望再完成转化。Agent 进来后这个链路被直接截断，电商转化率会持续承压，是主流平台中受冲击最直接的一家。

亚马逊

自营商品 + FBA 全球履约网络 + Alexa 语音入口，和京东的逻辑高度相似，凭借供给确定性成为 Agent 时代的核心赢家。

Shopify

不做流量竞争者，而是做 AI 时代的卖水人。推出 Agentic Storefronts 功能，一键对接所有主流 AI 入口，帮助商家接入全渠道 AI 流量，反而在浪潮中直接受益。

五、新的挑战者：中立第三方 Agent 的降维打击

一个容易被忽略的判断是：Agent 时代的真正赢家，可能不是任何一家电商平台，而是与平台利益无关的第三方中立 Agent。

平台自有 Agent 天然背负着 “屁股决定脑袋” 的原罪：它要优先推荐自营商品、高佣金商品、合作品牌，永远无法做到绝对中立。而第三方 Agent 没有广告主、没有佣金池，唯一的商业模式是让用户觉得它可靠、公正。对用户而言，更换一个 Agent 的成本趋近于零，信任会成为最核心的竞争壁垒。

当用户养成了 “先问中立 Agent，再决定去哪里买” 的习惯，所有平台自有 AI 入口都会沦为二级选项。这才是传统电商平台真正要面对的降维打击 —— 竞争不再发生在平台与平台之间，而是发生在平台与全新的决策入口之间。

写在最后

当前的 Agent 购物，正处在 “叙事跑在体验前面” 的阶段。技术上模型理解意图与匹配商品的能力还远未达到用户预期，商业上平台也不敢让 AI 真正实现全网比价。当前的真实状态是：传统投流广告不会死，但预算结构会持续重组；直播和短视频在 “制造欲望” 上依然无可替代，但短链路转化会被逐步截留；平台竞争从 “流量之争” 升级为 “AI + 生态 + 履约” 的三位一体竞争。

未来三年是关键观察窗口：究竟是现在的电商巨头能巩固优势，还是新挑战者能掀翻牌桌。

当决策的权力开始交给 AI，所有围绕 “人类注意力” 建立的商业规则，都值得被重新推演一遍。

PS：
1、信息的围墙，会被各大巨头构建的更高更厚，需要监管部门介入才能打通
2、为了避免被“管道化”，各大巨头一定会更拼命的想办法去吸引客户，而不是单纯做一个信息“管道”
3、即使信息被“管道化”，但各大巨头当前建立的生态也很难被击穿
4、传统电商广告和排名，会面临巨大的挑战
5、GEO可能会引入新的攻防大战

浅聊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系统时，选对那把“安全锁”。

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