这篇文章最该拿走的是工程判断

把压缩讲到流形、统计流形、宏和幺半群，很容易让人产生一种错觉：这套东西离软件研发很远，最多适合写一篇漂亮的科普。

我不这么看。它和 AI Agent、企业软件研发有关系，但关系不在那些名词本身。

真正有用的地方，是它换了一种方式描述“系统为什么会变好”。堆更多提示词、更多工具、更多接口，不会自动让系统变好。系统变好，是因为它把混乱的现实压成了更短、更稳、更可复用的结构。

企业软件一直在做这件事。CRM 把销售现场压成线索、客户、商机、阶段、活动。ERP 把组织运转压成订单、库存、采购、应收、应付、凭证。研发平台把软件交付压成 issue、分支、构建、测试、发布、回滚。

Agent 也在做同一件事，只是它面对的输入更乱：自然语言、网页、截图、文件、API、会议纪要、代码仓库、工单系统、历史对话。它要先把这些东西压到一个能行动的空间里，再把成功行动压成下一次可以复用的技能。

所以这篇文章对工程最有用的翻译是：

Agent 的核心不只是替人聊天，它是在把工作压缩成可执行结构。

几何压缩：先知道任务落在哪里

企业里的任务从表面看非常杂。

一个用户说“报销又被打回来了”，可能是发票抬头错了，可能是预算科目不对，可能是审批人离职了，也可能是系统规则改了。一个销售说“这个客户卡住了”，可能是价格问题、法务问题、安全审查问题，也可能只是内部 champion 换人了。

人类专家听完几句话，会很快把事情放到一个隐含坐标系里：这是什么类型的问题，归谁处理，风险多大，要查哪个系统，有没有先例，能不能自动处理，什么时候必须升级。

这就是 Agent 系统里的“几何压缩”。

原始输入是高维的。自然语言里有事实、情绪、噪声、省略、错误叫法和上下文缺口。Agent 不能逐字机械响应，它必须把输入映射到一个低维任务空间：

  • 意图是什么。
  • 对象是谁。
  • 当前状态是什么。
  • 缺哪些信息。
  • 需要调用哪些工具。
  • 风险边界在哪里。
  • 成功标准是什么。

这个过程对应到工程里，就是意图识别、任务路由、embedding 检索、案例聚类、工作流挖掘、RAG 召回、上下文构建。它们共同回答一个问题：这个任务在工作空间里的位置在哪里？

位置找错，后面做得越快，错得越快。

很多企业 Agent 的失败表面是答案问题，根上是第一步就把任务放错了地方。把投诉当咨询，把权限问题当操作指导，把合规例外当普通流程，把一次性人工判断当成可自动化规则。后面的工具调用、文案生成、状态更新，看起来都很流畅，但整个动作从根上偏了。

所以几何压缩对 Agent 的启发很直接：不要先沉迷“会不会调用工具”，先问系统有没有一个稳定的任务坐标系。

没有坐标系，Agent 只是一个会说话的执行器。

代数压缩：再把经验封装成 Skill

任务定位只是第一半。第二半是把做过的事留下来。

一个客服 Agent 第一次处理退款，需要读政策、查订单、看支付状态、判断是否超期、生成解释、写入工单。第二次、第三次还从零推理，说明系统没有学习。真正的沉淀，是把这条稳定轨迹压成一个 skill。

Skill 在这里比提示词模板更重。它更像一个宏。

宏的价值，是用一个名字封装一串动作。软件里的函数如此，数据库事务如此，CI 流水线如此，企业 SOP 也是如此。你不需要每次重新描述“查订单、核政策、看支付、写回复、留审计”，只要调用“处理退款工单”这个能力包。

好的 Agent Skill 至少要封装四件事。

  • 触发条件：什么时候该用，什么时候不该用。
  • 执行策略：按什么顺序做，调用哪些工具。
  • 终止条件：做到什么程度算完成。
  • 复用接口：能否被其他 skill 调用，输入输出是什么。

这和 2026 年的 Agent Skill 研究定义能对上。相关 survey 把 skill 看成包含条件、策略、终止条件和复用接口的结构化包；另一个关于 Agent Skills 的 survey 也强调，skill 是指令、代码和资源组成的可组合包，按需加载，而不是把所有过程知识塞进模型参数。

工程上，这个定义比“高级 prompt”硬得多。Prompt 改的是一次对话的行为，skill 改的是一类工作的执行方式。

企业软件本来就是一台压缩机器

很多人谈企业软件，会先看页面、流程、权限和报表。再往里看一点，会看到领域模型。领域模型才是企业软件真正的压缩物。

销售现场很乱，CRM 用 Lead、Account、Contact、Opportunity 把它压住。供应链很乱，ERP 用 SKU、BOM、库存、采购单、出库单把它压住。研发过程很乱，工程平台用 repo、branch、build、test、release、incident 把它压住。

这些对象不是自然界长出来的。它们是组织为了行动而发明的宏。

宏设计得好，系统就清楚。宏设计得坏，系统会把现实的混乱原样搬进数据库和界面里。比如把“客户”“合同主体”“付款主体”“使用组织”混成一个字段，早期省事，后期每个报表、权限和审批都会出问题。它不是代码问题，是压缩方式错了。

Agent 进入企业软件后，这件事会更明显。

如果底层业务对象含混，Agent 只会更快地暴露含混。它会在错误对象上检索知识，在错误流程里调用工具，在错误权限边界上生成建议。很多团队以为自己缺一个更强模型，实际缺的是一套能被模型稳定读取和调用的业务压缩结构。

企业软件的老问题，不会因为 Agent 到来而消失。它们会换一种方式回来。

可交换的流程才容易自动化

压缩理论里有一个很有意思的判断：交换性会极大影响压缩效率。放到工程里，可以翻译成一句更朴素的话：

步骤能不能换顺序，决定了系统好不好编排。

有些动作天然可交换。给客户打两个独立标签，顺序通常无关；跑多个只读校验，顺序通常无关；汇总几个互不依赖的数据源，也可以并行。

这些流程适合 Agent。它们可以拆分、并行、重试、缓存、复用。

另一些动作不可交换。先付款再发货，先审批再报销，先锁库存再出库，先迁移 schema 再发布代码。顺序一错，不是输出难看，而是业务事故。

这解释了为什么 Agent 在企业里不能只靠“多试几次”。对可交换任务，多试几条路径也许有用；对不可交换任务，错误路径本身就是风险。越靠近钱、权限、库存、法务和客户承诺，越需要状态机、事务边界、幂等设计、人工确认和审计日志。

这里的重点不是数学里的交换幺半群，而是工程里的可组合性。

一个企业 Agent 平台应该显式标注哪些 skill 可并行，哪些 skill 必须串行；哪些操作可重试，哪些操作只能先 dry run；哪些步骤只是读，哪些步骤会产生副作用；哪些输出只是建议，哪些输出会改变系统状态。

没有这些标注，Agent 的“自主性”只是把顺序风险藏了起来。

Skill 库会变成组织经验的压缩文件

当一个团队只有三五个 skill，手动维护还行。到了几十个、几百个，问题就会变成软件工程问题。

两个 skill 可能做同一件事。一个旧 skill 里的命令已经过期。一个第三方 skill 会访问不该访问的服务。一个自动进化后的 skill 删掉了原来的安全约束。某个 skill 在一个客户场景里变好，却在另一个场景里退化。

这就是前面那篇 Agent Skill 进化 survey 重要的地方。重点不在“19 种方法很强”，而在 skill 一旦成为资产，就必须有持续评估和治理。

一个企业级 skill 库至少要有六层治理。

  • 版本：每次修改都能看到 diff、原因和责任人。
  • 触发测试：不只测该用时能用，也测不该用时不会误触发。
  • 回归集：新 skill 不能破坏旧场景。
  • 权限边界：skill 能读什么、写什么、调用什么。
  • 安全约束：自进化不能删除更高优先级的规则。
  • 回滚机制：新版本出问题，可以退回旧版本。

这听起来像软件包治理，因为它本来就是软件包治理。只是包里装的不再只有代码，还有流程、工具、知识和判断顺序。

未来企业内部最值钱的东西，未必是一堆 prompt，更可能是一套被验证过的 work skill library：怎么做代码评审，怎么排查慢查询，怎么处理退款争议，怎么准备投标材料，怎么复核合同风险，怎么生成经营分析。

这些 skill 才是组织经验的压缩文件。

对研发团队，真正的变化在代码之上

AI 编程最容易被看见的是代码生成。代码确实会越来越便宜。但企业研发里更稀缺的，往往是把长期工作压成稳定结构，而不只是多写几行代码。

比如一个团队每次上线都靠资深工程师盯着，说明发布知识没有压缩好。一个团队每次排障都在群里临时问人，说明运维知识没有压缩好。一个团队每次接新需求都重新争论领域边界，说明业务模型没有压缩好。

Agent 可以帮你写脚本、补测试、改文档，但它更大的价值，是逼团队把隐性工作显性化。

过去很多工程经验活在人的手感里。现在如果希望 Agent 参与，就必须把这些手感写成可读取的结构：什么时候做，按什么顺序做，什么结果算通过，什么情况必须停下来问人。

这对研发管理的影响很大。

好的团队会开始把“经验”整理成可执行资产。它们不会只多写几篇没人读的流程文档，而会把流程变成 Agent 能调用、能验证、能回放的 skill。坏的团队会继续把经验散落在聊天记录、会议纪要和个人脑子里，然后抱怨模型不懂业务。

模型当然不懂。组织自己都没把业务压缩成可读结构。

不要把漂亮类比当成架构方案

这套压缩视角有用，但也有边界。

流形、宏、幺半群这些概念，不能直接变成一个企业 Agent 架构图。它们提供的是判断方式，不是实施方案。看到“几何压缩”，不能马上去加一个 embedding 数据库；看到“宏压缩”，也不能把所有 SOP 都塞成 skill。

工程里还要问更具体的问题：

  • 这个任务是否高频到值得封装。
  • 它的成功标准是否能被测试。
  • 它是否包含不可逆副作用。
  • 它的输入输出是否稳定。
  • 它是否依赖某个人的裁量。
  • 它变更后能不能做回归。

回答不了这些问题，封装得越快，债务越多。

压缩不是把东西变短就行。坏压缩会丢掉关键差异，把本来不同的场景硬合并成一个流程；过度压缩会让系统看起来优雅，实际到处是例外；压缩不足则会让团队永远在低层重复劳动。

企业软件研发最难的部分，就在这里：找到刚刚好的抽象。

最后回到 Agent

把这篇数学文章放进 Agent 和企业软件里，最后可以收成一个很实用的判断。

Agent 的第一层能力，是在任务空间里定位。它要知道当前请求属于什么类型，落在哪个流程，受哪些约束影响。

Agent 的第二层能力，是调用宏。它要把稳定的工作轨迹变成 skill，减少每次靠模型从零临场发挥。

Agent 的第三层能力，是治理这些宏。它要知道哪些 skill 可用、过期、冲突、危险、需要回滚。

这三层合起来，才像一个能进企业的系统。

只会对话的 Agent，不会留下多少组织资产。只会调用工具的 Agent，也只是更方便的自动化入口。能把工作不断压成技能、把技能不断纳入测试和治理的 Agent，才会改变企业软件研发。

未来的企业软件，表面上可能还是工单、审批、代码仓库、知识库和报表。真正变化的是底层多了一层可演化的压缩结构：现实任务被压成坐标，成功路径被压成 skill，组织经验被压成库，安全边界被压成门禁。

压缩不是把世界变简单。压缩是承认世界很复杂，然后为复杂找到能长期工作的形状。