AI原生组织转型:我们离自动驾驶研发流水线还有多远
- 2026-07-20 03:58:47
AI原生组织转型:我们离自动驾驶研发流水线还有多远技术负责人：带过几十个骨干后发现，混得差的技术人，不是能力不行，是学生思维太重 但跑了一段时间以后发现一个现象： 工程师写代码越来越快，但端到端的交付周期却没怎么缩短。 问题不在编码环节，而在编码前后的整个软件开发过程上。 AI 像一把锋利的手术刀，只切开了研发流程中间那一小段，前后还是靠人手工缝合。 具体来说，有几个场景特别典型: Agent 辅助生成技术方案和代码可能只要两天，但测试验证仍然需要四天。从提交 Bug 到定位、修复、回归，全程需要人工搬运日志、查询配置、比对代码、判断影响面。 PRD 从需求系统流转到代码实现时，业务背景、验收标准和上下游约束全靠人工复制粘贴，AI 很容易丢失上下文。 技改需求和线上告警处理流程分散在多个系统里，根本形不成自动化闭环。代码修复完成后，单元测试、集成测试、QA 自动化测试、人工回归、灰度发布、日志观测，仍然依赖人工串联。 发布后要不要放量、要不要回滚，还得靠人盯着日志、告警、业务指标和用户反馈。 这些不是工具不够强的问题，是流程没有贯通的问题。 AI 在单点上的效率越高，手动断点造成的浪费就越显眼。 我一直在想，有没有一种方式，能让任务从进来以后自己往下走，而不是靠人在多个系统之间搬运上下文。 后来我们做了一个尝试，我们内部起名叫 IssueOps。 
一个以 Issue 为中心，调度AI Agent自动完成研发任务的工程自动化平台。 它像一个研发任务操作系统/自动驾驶研发流水线，Issue 是任务，Agent 是执行进程，Orchestrator 是调度器，Context Gateway 是数据总线，CI/CD 和测试平台是外部设备。 类似 DevOps 是：Development + Operations 强调开发和运维一体化。 IssueOps 可以理解为：Issue + Operations 简单说，就是把 Issue 当成上下文的引力中心，让系统围绕 Issue 自动聚合完整信息，调度 Agent 完成计划、编码、测试、发布和观测闭环。人只在关键节点看一眼，点一下同意。 目前已经有部分业务在试跑。 当然这是我们自己的名字，业界也有人叫 Agentic SDLC，有人叫 Fully Agentic SDLC，也有人直接叫 Self-Driving Development。 目前确实没有一个被行业普遍接受的单一术语，能准确概括 Agent 自主跑通研发全流程这件事。
如果要选一个名字，我更倾向于 Autonomous Agentic Engineering。 Autonomous 强调系统不需要人一步步指挥。 Agentic 说明任务由能够理解目标、调用工具并根据反馈继续行动的 Agent 承担。 Engineering 又把范围从写代码拉回到完整工程，包含知识、环境、测试、部署、观测、回滚和治理。 AI Coding能力大概可以分为四个登记： 
L1 是 AI 辅助 AI 帮你补全代码、解释逻辑、给建议，但每一步都是你点鼠标。 人为主，AI 打辅助。 L2 是 Agent 裸跑 AI 能独立完成一个模块的代码生成和测试，但缺少规范、知识和上下文。 效果因人而异，同一个 Agent，给资深工程师用和给新人用，产出可能完全不同。 人需要补充大量上下文，效果不稳定。 L3 是 Agent 加知识体系 AI 能力进入正式研发流程。 公司有统一的知识库、规范、标准流程，Agent 能连接这些资产，按照预设规则端到端执行。 人定义目标，Agent 负责执行。 系统可以在限定场景内自己跑完大部分流程，但遇到复杂情况还需要人接管。 L4 是自主研发 多 Agent 协作，事件驱动，系统自主运行。 任务进来、分析、修复、测试、部署、上线，这条链路可以稳定自治。 人不再盯着每一步，而是管理目标、风险和例外。 从 L1 到 L4，中间还有一条演进路径：人机协作分层 → Spec 驱动开发 → Harness 工程化 → Agent Team。 我们现在的实践，大致处于 Harness 工程化往 Agent Team 过渡的 L3 到 L4 之间阶段。 L3 的底座已经搭稳，Agent 能连接知识库和规范，端到端跑通流程。 但 L4 要求的真正自主运行，也就是多 Agent 协作、事件驱动、人在例外时才介入，还没有完全达到。 已经越过了 AI 辅助编码和单点 Agent 裸跑，开始进入真正的研发生产方式改造。 只是从一条先进流水线走到组织级自主研发，中间还有几道坎。 说回我们自己。 以前工程师用 AI 写代码，是 prompt driven 模式。用户说一句，AI 做一步，用户继续补上下文，AI 再做一步。 状态留在聊天窗口里，换会话就丢失，上下文全靠人工复制粘贴，验收靠 AI 自评。 这种模式在单人写代码时还行，一旦放到团队流程里，就像用微信聊天记录来管理项目，信息散落一地。 我们现在的思路是 issue driven。 一个任务进来，先沉淀成结构化 issue，系统围绕这个 issue 自动聚合所有相关上下文：代码、日志、配置、CI/CD 结果、历史修复记录、知识库经验。 然后由 Orchestrator 调度多个 Agent 在隔离的 Workspace 里完成计划、编码、测试、Review、发布和观测。 最后 issue 关闭，才算任务真正结束。 关键区别不是技术多先进，而是任务管理方式变了。 普通 AI 编程是对话结束即任务结束，issue driven 是 issue 关闭才算任务结束。 在这个思路下，我们给每个仓库配了一套原生契约： AGENTS.md 定义 Agent 行为规范 WORKFLOW.md 定义工作流 TESTING.md 定义测试规则 RELEASE.md 定义发布策略。 这些文件跟着代码版本走，Agent 和人类看的是同一套规矩。 人机协作分工也很清楚。 Agent 负责机械性、重复性、上下文搬运型工作，比如自动聚合日志、生成测试用例、跑灰度观测。 人负责战略、架构、复杂业务判断和高风险决策，比如审批中高风险方案、把关核心链路变更、决定要不要回滚。 一条流程跑通，和整个组织能够规模运行，中间隔着几道坎。 自动驾驶有一个很朴素的前提，系统必须知道自己能在哪些道路、天气和速度下运行。 高速公路能开，不代表老城区小巷也能开。晴天能开，不代表暴雨天还要硬开。 研发自动化工作流也需要这样的边界。 哪些 issue 可以自动进入，允许修改哪些代码，能够调用哪些工具，什么风险等级可以自动上线，什么情况下必须停下来找人，这些都要提前写进系统。 我们内部按风险等级做了划分： R0 是低风险等级告警、日志打印告警、Agent 可以自动合并。 R1 是小范围 Bug 修复，可以自动修复提 PR。 R2 是普通 Feature，需要人工确认计划。 R3 和 R4 涉及关键核心链路变更，Agent 只辅助诊断和建议，禁止自动执行。 当然敢于让agent操作上线是需要勇气和相关机制。harness以及行业总结各种实践当然有必要：如多模型互相review、定义更多agent角色等，但我想说这些只能尽可能的保证把事情做对，没办法100%完全消除风险。 我们的实践是花大力气建设agent驱动的自动化回归平台，为整个流程兜底，也解决了传统自动化平台依赖人工维护用例，效率低、覆盖面不足的问题。 大概思路是agent负责回归用例构建、编排和调度自动化平台执行，并由评估agent评估执行情况，最终由报告agent生成整体报告。 回归用例的构建大量引用线上真实流量，更贴近业务，也减少了人工构建的成本。人在里面的角色更多的是制定标准和监督执行。 这其实是一个很大的话题，工程层面需要做大量的工作来保障，后面有机会可以开新的文章展开聊。 如果边界没有定义，Agent 越强，管理者反而越不敢放权。 公司下一阶段不需要追求所有研发任务都自动化。 先把一批验证场景跑清楚，在这个范围内做到稳定自治，再逐步扩到相邻场景。这比一上来宣布全面进入 L4 更可靠。 讲完了我们自己这条流水线的进展，我想跳出公司视角，说说为什么我认为这套思路值得所有研发团队认真考虑。 不是因为我们在做所以我说好。 是因为 issue driven 解决了一个困扰研发组织多年的老问题：工作项在人与人之间丢来丢去，每次交接都丢上下文、人工低效的问题。 具体来说，至少能解决三个痛点。 第一个是自动分派 以前靠人眼扫标题分任务，忙起来经常分错。 系统可以基于标签、关键词、历史数据自动路由，把缺陷分给Agent或者红对应的工程师来处理。 第二个是上下文关联 以前工程师接手 issue，要自己翻文档、查日志、问同事。 系统可以在任务创建时自动关联相关代码、日志、文档和类似历史 issue，让Agent一开始就有完整上下文。 第三个是状态更透明 自动化流水线把所有状态变化写在时间线里，谁都能看，不用挨个问。 这三个痛点，小团队可能感受不深，但团队过五十人以后，每天花在找人和对齐状态上的时间，累积起来非常惊人。 我不是说所有公司都要一步到位搞自动驾驶研发。 但建议从 issue 的自动分派和状态流转开始试水。 投入不大，收益可见，而且为后续接入 Agent 打下了流程基础。 这就像修高速公路，先通车，再考虑上自动驾驶。 有读者会问：你们这套东西是怎么搭的？ 我把自己调研过（几个月前）的几条路接单介绍下，只讲优缺点，你们按自己的生态选。 symphony + harness symphony 是 openai 开源的 issue 驱动 agent 编排框架，它把 issue tracker 变成长期运行的 agent 控制面，持续读取 issue、给每个 issue 创建独立 workspace、启动 coding agent、跟踪状态、失败重试。 我们把它当作平台骨架和调度内核。 优点是架构最贴近 issue driven 理念。 缺点是它只是个demo，不是完整产品，缺少 triage、context gateway、测试和发布闭环，需要你自己补齐。 目前为止我们已经二开增加了数万行代码。 GitHub Copilot Workspace 这是 GitHub 内的异步 Coding Agent，开箱即用，从 Issue 启动，自动改代码、跑测试、提 PR。 优点是上手极快，适合已经在 GitHub 生态的团队。 缺点是强依赖 GitHub，企业流程、QA 门禁和发布治理不可控，更像一个个人效率工具而不是企业级平台。 SWE-agent 这是开源的软件工程 Agent，可控可改，适合做真实仓库的 Issue 修复实验。 优点是透明度高，可以作为自研平台里的 Coder 执行内核。 缺点是它本身不是平台，没有企业流程、权限、审计和上下文网关，需要大量二次开发。 Devin 这是商业化的 AI 软件工程师，产品化程度高，适合端到端工程任务和并行云端 Agent。 优点是开箱即用，功能完整。 缺点是黑盒，成本和数据边界依赖供应商，难深度改造成内部平台。 适合快速采购试点，不适合作为底层可控架构。 我的建议是，不要一上来就追求最完美的方案。让团队先感受到 issue driven 的甜头。 我们当下选择的 symphony也不见得是最优的方案，可能几个月后业界又会有更好的框架出来，但当下我们踩过的坑和思考是可以积累的。 回到开头的问题。 公司现在整体处于 L3 到 L4 之间。 告警修复这条链路已经跑通了自动分析、修复、测试、发布和观测，看起来很像 L4。 但覆盖范围有限，异常处理还需要人兜底，组织责任机制还没完全从人转移到平台规则。 真正的 L4 不是某一条流水线跑得顺，而是整个组织知道什么时候该放手，也知道什么时候必须接管。 Agent 能做多远只是起点，公司能不能稳定接住它，才决定成熟度。 AI native 研发组织的目标，不是完全不需要人介入。而是把agent有能力处理的任务交给机器，需要架构取舍、业务判断和风险负责的路段，人还得握住方向盘。 13年技术路，6年管理路，呆过多家大厂，带过多种规模的技术团队。这里记录技术管理者的真实踩坑与成长。既关注技术管理，也关注技术架构，致力于技术管理和技术架构双线发展。 wechat公众号：无涯技术管理，关注我阅读更多技术管理文章，也欢迎与我私聊职场困惑、职业发展、技术架构等话题。
技术负责人给年轻人的忠告：努力先成为老板的价值嫡系，再谈其他
技术负责人给年轻人的忠告：将军赶路不追小兔，带过几十个骨干，最后成事的人都懂得这个道理
技术负责人给年轻人的忠告：单纯的技术没有价值，成功靠持续的做事
公司给研发团队配齐了最新的gpt和claude模型，编码环节确实提效了。为什么叫 IssueOps？
如果要选一个名字，我更倾向于 Autonomous Agentic Engineering。
AI Coding 能力分级
让 Issue 成为上下文的引力中心
先划定边界
建议所有团队都试试
如果你也想搭一条流水线，怎么选型
离真正的 L4 到底还有多远
本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：wyl860211@qq.com 。
