AI Agent 一周写完 20 万行代码？当整条工作流都被 Agent 承包 App 要学会认“任务流量”

五天搞定原本估计要干六个月的活、一周时间把 8 维和 24 维最优球体堆积定理都搬进 Lean 形式化世界、总代码量拉到约 20 万行——这就是 Math Inc. 的 Gauss 智能体在球体堆积项目里交出的新成绩单。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开 更重要的是，这次被形式化的不只是一篇论文，而是一整条“从读论文、查文献，到写代码、跑验证、自动纠错”的工作流，它几乎完全由一个 AI Agent 承包。Completing the formal proof of higher-dimensional sphere packing 当这样的 Agent 开始接管越来越多业务场景里的长链路任务时，App 再把世界理解为“用户点了哪个页面、哪条广告带来多少安装”，就有点过于天真了——你真正面对的是一种全新的“任务流量”。

新闻与环境拆解：从菲尔兹奖证明到 20 万行 Lean 代码

先把这次事件用几句话说清楚：

• 主角是谁：一家名为 Math Inc. 的创业公司，以及它的自动形式化智能体 Gauss。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开

• 做了什么：在 Lean 证明助手中，完成了 Maryna Viazovska 关于 8 维 E8 晶格和 24 维 Leech 晶格最优球体堆积定理的完整形式化证明，总计约 20 万行代码。Completing the formal proof of higher-dimensional sphere packing

• 有什么特别：这是本世纪以来首个被完全形式化的菲尔兹奖成果，同时也是目前历史上规模最大的单一用途 Lean 形式化项目之一。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开

更细一点看这条新闻里的关键特征：

• 时间尺度被压缩到“以周计”：人类团队原本预估 8 维情形还要花 6 个月，Gauss 在 5 天里补完剩余证明，又用约一周时间完成 24 维部分，整个项目从 7 万行拓展到约 20 万行。Completing the formal proof of higher-dimensional sphere packing

• 形式不是“辅助写作”，而是“整条 pipeline 自动运行”：它不仅写代码，还自己调 Lean 内核做验证，甚至在过程中发现并修正原论文里的符号和定义错误。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开

• 行业定位被提升到“自动形式化领域的 ImageNet 时刻”：许多数学家和观察者直接把这次成果视作一个阶段性拐点，意味着“AI 参与严肃数学推理”从小范围实验进入大规模实战阶段。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开

对 App 所在的终端和市场环境，这条新闻释放出一个明确信号： AI 不再只是“回答问题”、生成几段文案，而是开始在真实世界里承包长链路、高成本、高门槛的任务，而且交付物是可以被独立验证、维护和复用的。

从数学新闻到用户路径：当入口变成 Agent 工作流

如果把 Gauss 这次形式化任务当成一条“超长用户路径”，会发现它和今天很多业务场景其实高度相似。Sphere Packing Project Achieves Major Milestone with Gauss AI

在传统 App 视角里，一条典型路径可能长这样：

• 被广告 / push 触达

• 点击落地页

• 下载安装并首启

• 完成注册 / 授权 / 首单

你关注的是 PV、点击率、安装率、注册率和后续转化。

而在 Gauss 的这个项目里，“用户路径”则完全变成了 Agent 工作流：

• 起点，是人类团队在 Lean 项目里写好的“蓝图”和未完成的 sorry 占位符；

• Gauss 接到的不是“帮我写一段代码”，而是“把这整个球体堆积证明项目收尾”；

• 它自己拆解任务：读取论文和蓝图、检索参考文献、构造中间引理、生成 Lean 代码、编译验证、修正错误；

• 整个过程持续多天，最终产出的是一整棵“可编译的证明树”，而不是单一结果页。Completing the formal proof of higher-dimensional sphere packing

对应到 App 的世界，当入口从“人手点一个广告位”变成“某个 Agent 在一条工作流中需要你这个能力”，路径会发生几件关键变化：

• 触达不再是“曝光 + click”，而是“某个任务节点需要调用你的服务”；

• 决策者不一定是终端用户，而是替用户规划任务的 Agent；

• 同一用户可能在多个 Agent、多个任务中多次“路过你”，但用户自己可能根本没看过你的界面。

如果你仍然用传统 Funnel 去理解这件事，就会出现典型盲区：

• 你知道自己安装量涨了，但不知道究竟是哪个 Agent 工作流在疯狂给你派任务；

• 你看得到 API 调用次数，却看不到这些调用属于哪些任务、在任务图里位于哪一环；

• 你以为自己在优化“转化率”，实际上影响的却是 Agent 对你能力的复用意愿。

换句话说，入口不再是一个页面，而是一条工作流；用户路径不再是“人-页面-按钮”，而是“人-多 Agent-多 App-多终端”的任务编排。在这个新路径上，你需要的是“任务流量视角”的归因模型。

工程实践：如何把安装归因与全链路归因升级到“任务流量”视角

要从页面流量视角迁移到任务流量视角，App 侧至少要做三件具体的工程改造：给入口加上任务身份、把任务上下文带进来、在数据层画出完整的任务事件图。

入口层：用 ChannelCode + Agent 字段认清“谁在派任务”

在很多团队现有体系里，ChannelCode 已经被用来统一广告、联运、线下二维码等入口，但默认的“对象”还是人：某个用户通过这个渠道进来。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开

在 Agent 时代，同一个渠道下面会混在一起：

• 用户自己点击的访问；

• 某个公开 Agent（比如个人助理类应用）代用户发起的调用；

• 某个企业内部的多 Agent 工作流批量触发的任务。

如果继续只用 ChannelCode 做颗粒度，报表就只剩“这个渠道很好/很差”，完全看不到背后究竟是哪个 Agent、哪类任务掌握了流量入口。

更合理的做法，是在沿用渠道编号的同时，为“Agent 任务流量”增加一层结构化身份：

• channelCode：保持原有渠道维度，用于投放与统计；

• agent_platform：标记来自哪个 Agent 平台或任务编排系统（例如某开放指令集平台、某云厂商 Agent Hub 等）；

• agent_id / workflow_id：标识具体 Agent 实例或工作流模板/运行实例；

• scene：任务场景，比如“账号迁移”“账单整理”“智能选品”“数学练习题生成”等。

在具体命名和落地策略上，可以参考我们站内关于多云多 Agent 时代如何认清流量真身的文章，对 ChannelCode 体系做一次整体升级。《亚马逊 AI 战略升级？多云多 Agent 时代 App 该怎么认清流量真身》

这样，你在看渠道报表时，就能把“人物流量”和“任务流量”分展开看，真正知道是谁在帮你“带业务”。

参数层：用智能传参安装把任务上下文带进 App

Gauss 在形式化过程里，并不是只在一个空白环境里写代码，它有丰富的上下文：当前证明进度、依赖哪些文献、正在处理哪一块结构、之前 refactor 了什么。Completing the formal proof of higher-dimensional sphere packing

对于 App 而言，Agent 发起的每一次调用背后，同样有完整的任务上下文：

• 这是一个“拉新任务”还是“迁移数据任务”；

• 当前用户处在整个任务链路的第几步；

• 这个任务对结果有什么偏好（比如更看重速度还是精度）。

如果你在安装 / 拉起时不接收这些信息，只把它当成普通 install 或 open 事件，就等于主动放弃了“理解任务”的权利。

实践上，可以用“智能传参安装”的方式，把任务意图从入口端带到 App 内部：

• 在入口侧约定参数结构：

  • task_type：任务类型，如“导入历史聊天记录”“批量创建账单”“生成搬家指南”；

  • task_context：任务上下文，使用 JSON 编码，包括源平台、目标平台、数据范围、用户偏好概要等；

  • user_profile_hint：在隐私合规前提下，由 Agent 提供的一些高层偏好描述。

• 在 App 首启 / 唤起逻辑中，通过智能传参安装能力完整接收并落地这些参数：

  • 决定初始落地页和默认操作建议；

  • 将关键字段写入埋点事件，为后续分析与优化提供基础数据。

围绕安装传参与参数还原，我们在智能体分发时代已经做了不少系统性思考，可以参考站内文章深入了解具体工程方案。《智能体分发时代 App 安装传参逻辑的底层重构》

数据层：用“参数还原 + 事件模型”搭出一张任务事件图

Gauss 形式化项目最终呈现的是一幅“证明图”：每一行代码、每一个引理都是那张图上的一个节点，彼此之间有严格的依赖关系。Sphere Packing Project Achieves Major Milestone with Gauss AI

而很多 App 的埋点系统，更多是“点状事件列表”：点击、曝光、下单、支付成功……这在人物流量时代勉强可用，但面对任务流量就显得过于粗糙：

• 你看不到一条任务从入口到完成经过了哪些关键节点；

• 你无法区分任务失败是因为外部依赖失败、用户中断，还是 Agent 决策问题；

• 你也没法给 Agent 反馈“哪里最容易出错”“哪一步值得重试”。

改造方向，可以用“以任务为主语”的事件模型来重构数据层：

• 在事件设计上，把 task_id（或 workflow_run_id）提升为一等公民，与用户/设备并列；

• 把入口信息（ChannelCode + Agent 相关字段）写入任务的起点事件；

• 用标准化事件记录任务关键状态变更，例如：任务创建、排队、开始执行、调用外部系统、用户介入、结束（成功/失败/取消）；

• 在整个链路中，保证入口带来的 task_type、task_context 等参数在事件里得以完整保留。

有了这样的任务事件图，你就可以在 BI 和数仓层面：

• 从任务角度分析：不同 Agent 平台、不同任务类型在成功率、耗时、用户体验维度的表现；

• 找出任务失败的高频原因，并为 Agent 平台提供结构化反馈；

• 跨终端、跨系统地理解“同一任务”的全流程。

在智能体分发和技能生态场景下，围绕“任务流量”的参数和事件建模，我们也以 Skills.sh 为原型探索了一套新的归因范式，可以作为更深入的参考。《智能体指令集 Skills.sh 发布：AI Agent 分发生态下的 App 归因新范式》

这件事和开发 / 增长团队的关系

从工程和业务视角看，Gauss 的故事不是“数学界的八卦”，而是在告诉你：整条工作流被 Agent 承包以后，你的系统究竟要做哪些升级。

面向开发：为 Agent 预留接口和任务字段

对开发者来说，更重要的是“基础设施准备度”：

• 在 SDK 接入、服务端 API 设计中，为 agent_platform、agent_id、workflow_id、task_id 等字段预留位置；

• 在安装、拉起、关键业务事件的埋点中，引入任务维度，而不是只关注页面或按钮；

• 在接入未来可能的 Agent 分发平台时，统一使用 ChannelCode + 智能传参参数体系来识别入口与任务。

这些动作，短期看只是多加几个字段，长期看却决定了你能否在多云多 Agent 时代看懂自己的数据。

面向产品：把“Agent 用户”视作新物种

对产品经理而言，这条新闻提示的是一种新的“用户类型”：

• 人直接操作：传统意义上的 App 用户，关注的是点击路径、页面体验；

• 人在 Agent 建议下操作：人仍然是决策者，但 Agent 在背后推荐路径和动作；

• Agent 代为全自动操作：Agent 成为直接调用方，人只在某些节点授权或确认。

这三种模式在产品设计里的需求完全不同：

• 人看的是界面，Agent 看的是接口和状态机；

• 人习惯的是多选项决策，Agent 更需要明确定义的任务 API 和错误码；

• 人会容忍某些“体验妥协”，Agent 更在意的是可预期行为和稳定 SLA。

如果你还用“给人看的 UI”来服务 Agent，自然会有大量潜力被浪费。

面向增长与数据：把 Agent 当作新渠道和新合作伙伴

对于增长和数据团队而言，Gauss 这类 Agent 的出现，相当于多了一批极其高效、可规模化、且有明确偏好的“超级渠道方”：

• 它们不一定出现在你熟悉的广告平台后台，而是以 API 调用、技能调用、任务编排的方式接入；

• 它们评估你的标准，也不再只是“点击率”和“安装成本”，而是任务成功率、调用稳定性和上下文友好度。

因此，你需要在渠道策略和数据看板里：

• 明确设立“Agent 渠道”这一类目，单独看预算、成效和趋势；

• 区分 Agent 带来的新增任务 vs 传统人群带来的新增用户，采用不同的运营与评估方式；

• 建立与 Agent 平台的对账与反馈机制，从任务级别而不是 install 级别对齐认知。

常见问题（FAQ）

这种 Gauss 级 AI Agent 离我的 App 还很远，现在就要为“任务流量”做准备吗？

从技术复杂度看，Gauss 属于前沿中的前沿，但它代表的形态——长链路任务被 Agent 接管——在客服机器人、运营自动化、内部 Agent Hub 等场景已经非常现实。AI Agent搞定世纪首次菲尔兹奖成果形式化！一周时间独立完成，20万行代码已公开 现在做 ChannelCode 升级、参数字段预留和任务事件建模，成本相对低、侵入性小，却能保证两三年后 Agent 流量真正到来时，你不用“推倒重来”。

如果我们暂时接触不到任何智能体分发生态，现在做哪些事不会白费？

可以先在现有业务里引入“任务视角”：为跨页面、跨端的复杂流程定义 task_id，在事件中串起从入口到完成的一整条路径。 同时，在新活动、新渠道落地时统一采用 ChannelCode + 智能传参与参数还原的方式，让数据模型天然兼容未来的 Agent 场景。

终端 / 平台已经提供归因与报表了，自建“任务流量”视角是否重复建设？

终端和平台的报表往往从自身出发，只覆盖链路的一段，而且是黑盒聚合数据，很难回答“在你自己系统里的那一截到底发生了什么”。 自建的任务事件图和归因模型，是把视角拉回到你的业务本身：在多平台、多 Agent、跨终端的世界里，你始终持有一份完整、可追溯、可解释的任务真相。

在日志里区分人物流量和任务流量，会不会让埋点和分析变得更复杂？

复杂度确实会上升，但这是“必要复杂度”：人物流量的优化关注用户体验和转化，任务流量的优化则关注任务成功率、Agent 体验和调用稳定性。 把两者混在一起，只会让你的优化指标变得模糊，甚至出现“改了人类体验，反而伤害了 Agent 使用”的反效果。

任务流量会放大安全与风控的压力吗？应该怎么应对？

Agent 调用频率高、自动化程度强，确实会放大风控难度，但也带来精细化治理的机会。 如果你在任务事件模型中引入诸如 risk_level、agent_trust_score 等字段，并结合任务链路分析异常行为，就有机会比传统账号/设备模型更早发现风险模式。关键是在设计 ChannelCode 和任务事件体系时，让安全团队尽早参与。

行业动态观察：Gauss 之后，App 分发进入“任务时代”的前夜

在数学领域，Gauss 完成菲尔兹奖成果的形式化，被很多人视为“人机协作的新阶段”，因为它不再是“AI 写了一段漂亮的证明草稿”，而是提交了一份可以被 Lean 内核完全校验的、可维护的工程成果。Completing the formal proof of higher-dimensional sphere packing 类似的叙事，正在软件工程、运营自动化乃至 App 分发世界里发生：

• 昨天，Agent 多半还停留在“写一段脚本”“做一份汇总”的 demo 阶段；

• 今天，像 Gauss 这样的 Agent 已经在真实项目中扮演“高级协作者”，承担过去需要专家团队数月完成的工作；

• 明天，对 App 来说，更常见的入口不再是广告位或 icon，而是某个看不见的 Agent 在一条工作流里的调用。

对 App / B2B 团队而言，现在是一个微妙的窗口期：

• 一方面，任务流量还处在早期，数据量可控，历史包袱有限；

• 另一方面，如果不趁这个阶段把 ChannelCode、智能传参与任务事件模型搭好，等到 Agent 流量真正占据主导时，再补数据体系就会变得非常痛苦。

Gauss 用 20 万行形式化代码证明了一个数学事实，也顺便证明了一件更现实的事：整条工作流被 Agent 承包，不再是科幻小说，而是可以落在 GitHub 和生产环境里的日常。 当那一波任务流量真的开始涌向你的 App，你是否已经准备好，用一套面向任务的渠道、参数和事件体系，把它看清楚、接住、并且用好。