从Agent平台到产研自动驾驶:我对团队AI主线的阶段性思考
最近一段时间，我一直在准备集团半年度战略会的技术汇报。平台做到了哪一步，上线了多少Agent，覆盖了哪些部门，这些都有现成材料。真正让我停下来的，是整理时反复出现的几个问题：Agent上线了，用户为什么不用？两个组织为什么不能共用数据和应用？AI写代码越来越快，为什么项目交付没有同步变快？一个测试Skill，怎样才能保证100%不出错？这也是我有一段时间没有写公众号的原因。每次觉得一个方向已经成熟，执行过程中又会出现新的问题，原来的判断也得跟着调整。一线探索乱一点很正常。技术变化太快，很多方向必须先试，做着做着才知道有没有价值。但作为管理者，我不能长期说不清主线。否则产品、研发、QA、设计和运营只能跟着一个个临时需求往前冲，每个人都很忙，却很难判断今天做的事情和团队长期方向有什么关系。我们并不是毫无方向地做项目。开始时，我心里有一张大致的图：让AI进入业务，也进入技术团队自己的生产过程。真正执行以后，应用、底座、Coding和过程观测的问题不断从不同项目里长出来，原来的图也被越来越多细节打散。借着这次整理，我又把这些分支归置到一起，逐步收敛成Agent应用、Agent Runtime、AI Coding和Agent Desk四条工作线。这不是凭空想出的分类，而是原有方向经过半年实践后的又一次迭代。这些问题一直在修改我们的答案。梳理到最后，我看到的是两套正在形成的系统：一套让AI进入部门业务，一套让AI进入产研交付。管理对象也从模型、工具和单个Agent，扩展成一套可以运行、可以约束、能够留下证据并持续改进的组织生产系统。一张图，四条工作线，两套系统
第一套是企业Agent系统。Agent应用把部门SOP和专业经验变成员工真正使用的产品；Agent Runtime负责上下文、Skill、Tool、权限、版本、执行环境和运行恢复。应用验证业务价值，Runtime保证它能在企业环境里长期运行。第二套是AI原生产研系统。AI Coding建设需求、设计、研发、QA、发布等环节的执行方法和质量门禁；Agent Desk采集过程信号，逐步连接任务、会话、代码、测试、Review和交付结果。四条线有各自的判断标准：Agent应用看活跃、复用和任务完成；Runtime看稳定、恢复、权限与成本；AI Coding看交付周期、质量门禁、返工和工程资产；Agent Desk看过程是否发生、结果是否有证据、问题能否回流。这张图是我们现阶段的技术演进路线图，用来指导接下来往哪里投入、各岗位分别建设什么，以及几条技术线怎样衔接。它只适用于当前阶段，模型、工具和业务继续变化，我们也会继续调整它。Agent应用：同一个Skill，怎样长成五种业务形态
部门Agent落地以后，我们逐渐发现，应用形态不能用外面是不是一个聊天框来判断。真正决定它怎样建设的，是业务任务要在哪里完成闭环。我们把Skill作为统一能力底座。只需要固化方法、判断和交付标准时，它是方法编排；知识持续变化、结果需要依据时，它接入授权知识和实时上下文，成为知识增强；任务需要生成、解析、计算、保存或者校验真实产物时，它进入工具执行。再往外扩，涉及业务系统的查询和操作，就要通过Gateway处理身份、权限、确认和审计，形成系统协同；当任务需要专用界面、业务状态和完整流程时，就由UI或者Runtime API承载，成为可以持续使用的业务产品。这五种形态不是成熟度等级，也不要求一个Agent按照顺序逐级升级。同一个部门Agent往往会组合其中几种能力。任务在哪里闭环，能力就接到哪里；每新增一种能力，也要同步补上对应的开发、权限和治理。现在，平台里已经有产品、设计、运营、数据、审核、客服和研发协作等多类应用。用户先愿意用，技术才有机会产生价值
技术团队会关注模型、Prompt、Skill和上下文做了多少优化，普通用户往往没有明显感知。后来我们在首页增加典型任务和发言模板，告诉用户“这个Agent能做什么，第一句话可以怎么说”；又增加右侧产物预览，让用户一边对话，一边查看和修改Markdown、文档、表格或者HTML。用户的反馈反而非常直接：产品一下好用了。用户不关心预览是怎样渲染的，也不关心后面调用了多少模型和工具。他在意的是能不能理解入口、看见过程、确认结果，并把产物接着用下去。所以我也调整了团队的考核方式。相比“上线了多少个Agent”，现在更应该追问：每天有多少人使用？多久用一次？完成了什么任务？为什么第一次用完就不再来了？一次成功任务消耗多少资源？Agent数量说明建设规模，Token反映负载和成本，都不能单独证明业务价值。用户先愿意用，后面的技术能力才有机会产生结果。随着岗位和应用越来越多，我们面对的也不再只是某个Agent好不好用。不同身份可以访问什么，任务中断后怎么办，Skill和Tool升级会不会影响历史任务，这些问题开始把平台推向更完整的Runtime。Agent Runtime：把对话变成可管理的执行
Agent只做问答时，一个模型接口、一个聊天页面和知识检索就能工作。任务一旦开始访问内部系统、修改数据、运行脚本、等待审批，或者持续几十分钟，系统面对的就是一段需要被管理的执行过程：上下文能不能复现？工具有没有真实身份？任务中断后能不能恢复？资源升级以后，历史会话会不会漂移？刚开始建设平台时，我们对这部分工程很谨慎。Agent调度、事件、执行环境、版本、权限和审计都很重，团队更倾向于利用成熟生态，把精力放在Skill和业务场景。持续使用AI Coding以后，我们能够承担的工程复杂度被放大，原来不敢展开的部分也开始逐项落地。模型、云和工具依然属于开放生态，企业自己的运行规则和治理边界则需要逐步掌握在自己手里。这套架构想解决的其实是三件事：同一个任务能够复现，执行中断以后能够恢复，Agent只能在授权环境里做被允许的事。对应到架构里，就是三个关键设计。可复现的Thread。Thread创建时冻结模型、Prompt前缀、Skill、Tool、执行环境和对应版本，历史以追加方式保留。后台配置继续变化，也不会悄悄改变已经开始的任务。事件化、可恢复的运行时。用户消息、工具结果、审批、回调和中断被转化为持久化事件，前端和外部系统读取由事件生成的状态视图。页面刷新、连接断开、服务重启或者执行节点切换后，任务仍然能够恢复和对账。流式输出解决用户能否实时看见，事件化运行时解决系统能否记住发生过什么。受治理的执行环境。Worker通过注册和心跳接入，Agent可以在授权范围内选择云端沙盒、内网服务器、构建机、GPU工作站或者用户电脑。Runtime统一处理环境发现、身份权限、Workspace绑定、超时取消、失联恢复和工具副作用。知识也不必全部搬进统一RAG，数据库、代码、文档和实时状态可以留在原系统，由Skill规定何时访问、怎样验证。这三个设计最后落到同一个控制面：谁可以使用哪个Agent，Agent可以访问什么，运行的是哪一版资源，失败怎样恢复，成本归到哪里。从一套平台复制到两个独立组织
我们已经让这套私有化、受管、可恢复的Runtime在两个相互独立的组织中运行。我们所在的是集团下面的一家业务公司，集团中台和其他业务公司虽然属于同一个集团，但业务、权限体系和数据责任彼此独立。集团中台的法务、行政、结算和数据等部门希望使用Agent，合同、结算和经营数据却不适合进入业务公司的实例。因此，我们为集团中台单独部署了第二套平台。服务与数据库、身份与权限、知识与文件、Agent与Skill都保持独立，同时复用同一套平台能力和部门共建方法。这次从1到2的复制，让我们对“平台化”有了更准确的理解。复制的不只是一套页面和代码，还包括部署、运行、治理和共建方法；各个组织的数据、权限和专业资产又必须保持独立。从2走向N，还需要更多真实组织继续验证。AI Coding：没有100%的标准答案
AI Coding是我在外部交流中被问得最多的地方：有没有一个Skill，可以保证测试100%不出问题？能不能给AI一句话或者一份需求文档，它就完成开发、测试和上线？有没有一套现成的Skill目录，可以直接拿走？这些问题都在寻找一个确定答案：只要找到正确工具、Prompt或者Skill，AI Coding就能稳定地把事情全部做完。大模型的输出来自概率预测。需求是否完整、项目上下文是否准确、代码库有什么历史约束、工具拥有什么权限、什么结果算通过，也都因团队和项目而异。一个团队验证有效的Skill，换一套技术栈、业务规则和发布环境，就需要重新验证。大家最想得到可以直接复制的标准答案，真正的专业建设却要从承认“没有标准答案”开始。AI Coding要做的，是给不确定的生成过程持续增加上下文、约束、验证和反馈，把偶然有效的方法沉淀成团队能力。从统一工具，到统一执行体系
我们先统一了四件事：技术部门全员使用Codex作为Agent开发入口；以Harness Engineering建设工程方法和质量门禁；按照统一目录沉淀公共与项目Skills；通过Codex Plugin和Agent Desk采集过程证据。统一Codex不是工具偏好，而是在建立组织级的执行入口。入口统一以后，Harness规则才能进入真实开发过程，Skills才能按同一套规范加载，Plugin和Hook才能稳定采集事件。否则每个人使用不同工具、提示词和目录，团队很难复用经验，也无法形成共同的质量标准。技术项目中的Skills也有明确边界：可跨项目复用的公共组件和技术能力进入common，Harness Engineering维护通用工程方法，项目创建、项目开发、客户端和服务端规范按照职责分层；非公共业务知识留在项目自己的边界里。目录要回答的是：这是谁的经验，适用于什么范围，由谁维护。在通用研发方法这一层，我们把自研的Harness Skills封装成团队统一安装的研发方法插件，覆盖仓库上下文、产品意图、系统设计、执行计划、质量评估、发布反馈和复盘改进。Superpowers等同类插件不再并行安装，避免多套指令、工作流和触发规则同时生效，在Codex执行时互相冲突。一个Skill不会因为写得详细就自动变成标准。它必须进入真实任务，接受代码检查、测试、Review和人工验收；失败以后还要判断是上下文缺失、方法错误、工具失效、门禁不足，还是业务目标发生了变化。QA现有的接口自动化、移动端真机验证和发布辅助Skills，也都依赖具体环境、设备、权限和检查清单。文件可以复制，质量结果不能复制。概率内核，需要确定性外壳
我们把AI Coding可靠性的工程模型概括成“概率内核＋确定性外壳”。模型负责理解、生成和判断，外层系统负责Schema校验、权限检查、静态分析、类型检查、自动化测试、CI/CD、Dry Run、人工确认、灰度、监控和回滚。工程的目标既包括提高做对的概率，也包括做错以后及时发现、在正确节点阻断，并把问题送回需求、设计、实现、测试或者发布阶段。人仍然不可缺少。人可以减少亲手执行的次数，但必须负责目标设定、关键方案、例外处理、风险接受和最终验收。我们能够降低人工介入的频率，不能把最终责任一起交给概率模型。Agent Desk：让过程和结果留下证据
如果要求每个研发手工记录这次用了什么Skill、有没有做Plan、跑过哪些测试，很快又会变成一套为了管理而填表的流程。所以我们通过Codex Plugin和Hook自动采集会话、工具调用、Git、Plan、Review和部分验证信号，Agent Desk再把这些信息与需求、版本和项目逐步关联起来。看到研发进入过Plan或Review环节，只能证明这个动作发生过，不能证明计划合理、代码已经合格。Agent Desk还需要继续连接任务、代码变更、测试结果和人工结论。完整闭环应该是：真实任务暴露问题，Agent Desk留下证据，团队完成归因，改进Harness或Skill，再进入下一次交付。产研自动驾驶，是目标，也是组织的共同坐标
当编码动作被AI加速，需求等待、设计缺失、接口不清、测试返工和发布准备就会成为新的瓶颈。只优化Coding这个点，项目周期不一定同步缩短，还可能把更多问题推向下游。所以我们把“产研自动驾驶”设为长期目标，正式含义是AI原生端到端产研交付。它不追求无人参与，而是让AI在明确的上下文、岗位责任、质量门禁和权限边界内承担更多标准化执行；人负责目标、取舍、判断、验收和风险。这套目标由三类契约支撑：流程契约规定每个阶段的输入、输出、责任人和进入条件；岗位契约要求每个岗位在完成任务的同时沉淀模板、规范、Skill、知识或者组件；质量契约要求需求、设计、代码、测试和发布经过可验证门禁，发现问题按根因回流。这里有一个我们很看重的工程判断：阶段产物就是不同岗位之间的API。上游产物结构不稳定、字段不完整，下游Agent再聪明也只能猜。输入契约稳定以后，模型能力增强才会真正转化为自动化范围的扩大。H5试点：把端到端目标放进真实交付
H5智能交付是第一个项目级试点。下面这张图来自真实项目方案，完整呈现了当前设计的交付闭环。H5只是第一块试验田。需求、方案、开发、部署、测试和上线这条主链，以及阶段之间的输入输出、门禁和回流，对其他软件项目同样成立。图里最值得看的，是R1到R7七条回流线。需求、方案、Coding、测试、验收和上线任何一个环节暴露问题，都要按照根因回到上游，修正基线并重新经过对应门禁。允许AI犯错，也允许Skill从不完整开始
所以“允许AI犯错误、允许Skill从不完整开始”不是另外创造的一条理论，而是这套真实流程接受的前提。我们没有假设AI第一次就能把需求、方案、代码和测试全部做对，也不要求一个Skill刚写出来就是100分。流程真正要求的是：错误能够被发现，问题回到正确阶段，修正后重新验证，有效经验再沉淀回模板、文档、Skill、工具或者门禁。这和现实中的团队磨合很像。一个新人不会入职第一天就完全理解业务，成熟团队也不是靠一份完美制度建成的。AI进入团队以后，过去主要留在人脑里的经验，还要被写成Agent能够读取、系统能够检查的资产。产研自动驾驶让产品、设计、前端、服务端、QA、发布和运营有了共同方向。今天大家仍然在做单点提效，但每个点都知道未来要接到哪里：产品沉淀AI友好的需求和验收标准，设计沉淀状态、组件和生成规则，研发沉淀公共组件、技术规范和项目Skills，QA把需求和风险转成可执行验证，发布和运维沉淀灰度、监控与回滚规则。节目单、常规活动页等真实需求已经通过Agent完成部分页面生成、预览、修改和上线，证明部分节点可以进入生产。这不等于全链路已经自动驾驶。接下来要验证的是七个阶段能否连续流转，问题能否准确回到上游，成熟做法能否抽取成跨项目资产。“自动驾驶”现阶段最大的价值，是让不同岗位对AI时代的工作方向有了共同认知。模型会变，人和AI的分工也会变，但软件生命周期、阶段契约、质量门禁和责任边界相对稳定。大家知道自己的能力应该往哪里积累，今天的单点提效最终要为怎样的系统服务。我现在理解的团队主线
我的判断一直在变化。以前觉得团队暂时承担不了的复杂工程，AI Coding帮助我们一点点做了出来；以前觉得Agent和Skill上线就算落地，现在更关心有没有人持续使用；以前把AI Coding理解为开发提效，现在它已经扩展到完整产研流程。最近看到月之暗面一套关于AI Native人才的观点，其中第一条是“Curiosity > Being Right”，好奇心比一直正确更重要。我很认同。AI发展太快，很多问题没有现成答案，为了证明过去一直正确而拒绝调整，反而会让团队错过真正的变化。但对管理者来说，好奇心还需要落到组织里。一线可以大胆试错，管理者要给这些试错一个方向，还要建立发现问题、回到上游、重新验证和沉淀经验的机制。否则探索结束以后，组织留下的仍然只是几个项目和少数人的经验。这也是我这次梳理以后，对“主心骨”更具体的理解。它不要求我提前猜中下一个模型、工具或者最终形态，而是要让团队知道为什么出发、各自积累什么、怎样判断有没有进步，以及错误发生以后怎样让系统变得更好。四条工作线以后还会调整，产研自动驾驶也离真正实现很远。但产品、设计、研发、QA和运营已经知道，自己今天沉淀的东西将来要接到哪一段流程里。对一支正在进入AI协作方式的传统互联网团队来说，这条共同的方向，比某一次项目做得多漂亮更重要。如果每次试错都能留下新的上下文、规则、Skill或者门禁，团队积累的就不只是一批AI项目，而是一种持续学习和修正的能力。这是我想通过这次梳理，给自己、也给团队的一个交代。我是冰叔～
想一起聊的话，扫下面的二维码加我。
