从AI Coding到Harness Engineering的端到端工程开发实践应用宝活动平台系统支撑应用宝内包括 app、pc、手助等产品的所有日常/节假日活动在今年上半年我们针对整套系统进行了一次完整的重构。正值这个时间点Harness Engineering 的概念被提出我们团队也在重构的过程中针对新的活动平台系统引入 Harness Engineering 的工程实践初步搭建了一套 AI 端到端的开发流程。这篇文章主要记录了团队在践行 Harness 工程化过程中遇到的一些问题以及实践经验抛砖引玉欢迎其他团队同学一起探讨。一、为什么要实践 Harness Engineering在最初的开发阶段我们主要采用对话式 AI coding 的方式进行开发通过 CodeBuddy Plan Mode、Rules Prompt、AI 辅助编码、人工 Review 这样的协作方式让项目跑起来。这种开发方式在实现一些一次性任务、或者小需求的时候会非常快但随着项目复杂度的提升逐渐暴露出了几个明显问题1.1 单窗口上下文快速膨胀为了让 AI 能清晰的知道我们的业务背景、代码规范、项目结构等等往往我们每次都需要在给 AI 的 prompt 中输入这些信息。为了避免每次重复输入这些信息我们会将团队的一些背景知识、代码规范、生成规则等沉淀为文档或 rules在每次对话中塞到上下文带给 AI。[图片上下文膨胀示意]随着项目迭代知识背景、规则会越来越多每次启动上下文窗口还没输入需求就已经塞了很大一部分内容。另外如果在单一窗口下让 AI 实现需求往往多轮交互下来上下文会快速膨胀出现有损压缩导致遗忘、不按规则生成等等情况。1.2 缺乏完整的业务知识每次需求开发都依赖人在 Prompt 中讲清楚需求背景、涉及业务的知识等等信息而一个需求往往可能涉及多个业务、多个服务这些服务之间如何合作、如何实现串联都需要人来捋清楚后喂给 AI一个完整的上下文构造非常耗费精力。1.3 缺乏工程上的自动化闭环对话式 AI coding 的方式仅仅只能在 coding 环节由 AI 实现但一个需求的完整交付还包括了需求分析拆解、测试环境部署、接口验证、测试等等环节这些环节依旧需要依赖人来执行和验证。如果希望在这些环节也都能让 AI 参与真正做到 AI 提效就需要从工程上实现全流程的 AI 能力集成实现从需求到上线的闭环。1.4 单窗口无法并行在一个窗口内对话一次只能执行一个任务当需求涉及多个独立的开发任务例如开发三个独立接口要么只能一个一个让 AI 开发要么就只能同时开三个窗口分别跟 AI 对话让其执行。同时人需要在其中不断切换窗口进行对话以推动流程往下推进。总的来说当任务越是完整、越是规模化、越是可抽象成稳定流程其仅仅采用对话式 AI coding 来完成的弊端就越明显采用 Harness 工程实践的价值也就越高这也正是我们希望从对话式 AI coding 走向 Harness 工程化的原因。同时我们也想借此探索一下在真实业务研发场景中当下大火的 Harness 工程究竟该如何落地实践。二、整体架构知识库工程 ✖️ 端到端开发工程应用宝活动平台的 Harness 工程主要包含了两部分工程能力知识库工程和基于知识库之上构建的端到端开发工程。[图片Harness 工程整体架构]知识库工程负责将散落在代码、文档、可观测系统中的工程知识按照一定结构进行沉淀和更新并提供给上层端到端开发工程消费。整个端到端开发工程以状态文件为驱动实现了将一个需求由 AI 按照需求拆解-需求澄清-任务拆解-并行开发-单测校验-代码审查-测试环境部署-用例请求构造-接口验证-提交代码全流程执行人在其中只负责核心关键阶段的决策和信息补全。当前我们的整套体系包含 800 结构化文档知识范围涵盖后台 90 个微服务端到端流程沉淀了 12 个专家 Agent、30 业务相关 Skill 以及 10 个固定流程脚本。可以看到知识库工程是整个 Harness 体系的底座——上层端到端开发流程的每一个环节从需求拆解到接口验证都依赖它提供准确、结构化的业务上下文。因此本文会先从知识库工程开始介绍再展开到端到端开发工程。三、Knowledge Engineering——让 AI 真正懂业务在复杂业务系统中AI 最大的问题并不是不会写代码而是缺乏真实、准确、持续更新的业务知识作为背景上下文。前面提到对话式 AI Coding 的一个核心痛点是缺乏完整的业务知识——每次开发需求都需要人先把需求涉及的多个服务、业务背景、接口调用关系等捋清楚再逐条喂给 AI。更关键的是这份上下文是一次性的这次讲清楚了下次换个需求、换个窗口又得从头再来。如果没有一套系统化的知识管理机制AI 在每次执行任务时都相当于从零开始理解业务。因此知识库是整个 Harness 工程体系的基石——它决定了 AI 在需求拆解、技术方案、代码生成、接口验证等每一个环节中能否拿到正确、充分的上下文。知识库建设得好不好直接影响到整个端到端开发流程的整体效果。但是知识库体系的建设目前也是业界的一个比较大的难点在我们团队实践的过程中其难点主要有以下几个冷启涉及的知识数据规模大应用宝游戏研发后台业务覆盖了游戏宝券/礼包、活动平台、私域运营、微下载等多个业务域维护着数百个微服务每个服务涉及多则十几二十个接口仅接口文档这块其梳理、编写涉及的工作量就非常大更不用说还有业务逻辑、领域知识等内容。大量知识背景下如何精确提取知识在大量业务知识的情况下针对每一次问答如何用好知识准确查询出需要的内容也是一个需要解决的问题。知识更新迭代速度快已有知识容易过期随着产品的持续迭代无论是代码还是业务形态的更新都非常快在以前的文档中代码改了但文档没改的情况几乎是常态。一份写于半年前的业务梳理文档往往已经和现在的逻辑严重脱节。业界当下对于知识库如何组织也有非常多的讨论LLM Wiki、Obsidian-Wiki、GBrain 等等或方法论或实践方案也层出不穷。这里借鉴 LLM Wiki 和 Obsidian-Wiki 的方法论和实践我们团队搭建了一套结构化的知识库由两部分协同构成自动生成部分通过 Skill 体系让 AI 自动读代码、自动生成结构化文档、自动维护新鲜度。手工沉淀部分由人在custom.md和common/中沉淀业务背景、架构决策、使用规范等 AI 难以从代码中提取的知识。两者结合形成AI 生产 人工补充 AI 消费的知识库体系为 Harness 工程提供持续更新的知识信息。[图片知识库结构示意]3.1 整体目录结构llm-knowledge/ ├── backend/ │ ├── overview.md # 全局总览 │ ├── business/ │ │ ├── private_domain/ # 商城会员域 │ │ ├── activity/ # 活动平台域 │ │ ├── yybgame/ # 福利平台域 │ │ │ ├── meta.yaml # 服务索引 │ │ │ ├── custom/ # 域级手工文档 │ │ │ └── service_name/ │ │ │ ├── overview.md # 等8类自动生成 │ │ │ └── custom/ # 服务级手工文档 │ │ └── ... # 更多业务域 │ └── common/ # 公共知识库 │ ├── conventions/ # 开发规范 │ ├── lib_usage/ # 常用库指南 │ └── tech/ # 技术专题 └── .codebuddy/skills/整个知识库结构分为三层总览层backend/overview.md描述所有业务域的关键词和服务范围知识库查询的第一入口域层{group}/meta.yaml {group}/custom/机器可读的服务索引 业务域级别的手工沉淀文档服务层{service}/*.md {service}/custom/每个服务 8 类自动生成文档 手工补充文档同时文档文件分为两类一类是人工手动沉淀的文档另一类则是通过 Skill 自动生成的文档。手工沉淀文档位置用途{service}/custom/或{service}/custom.md服务级手工文档业务背景、调用示例、架构决策、历史包袱说明等 AI 难以从代码推断的知识{group}/custom/或{group}/custom.md业务域级手工文档跨服务的业务流程说明、领域概念定义、常见问题汇总backend/common/跨业务域公共知识库开发规范conventions/、常用库使用指南lib_usage/、技术专题tech/自动生成文档文档面向读者内容overview.md所有人定位、核心能力、技术栈、目录结构interfaces.md使用方 / AI所有接口、参数、业务说明、近7天调用量architecture.md开发者 / AI核心数据流、定时任务、Kafka 消费者、关键设计模式dependencies.md开发者 / AI上游服务依赖及调用方式storage.md开发者 / AIMySQL Redis Kafka 等存储组件config.md运维 / 开发者Rainbow Wuji DB 动态配置pitfalls.md开发者 / AI开发坑点含位置、描述、避坑建议log.md所有人文档变更历史每次生成追加不可覆盖手工沉淀文档与自动生成文档在知识库中地位等同kb-query在查询时会同时考虑两类来源。3.2 知识生成从代码到结构化文档的自动化流水线在知识的生成上我们定义了两个 skillgen-project-docs和batch-doc-generator分别支持单服务的文档生成与批量多服务文档生成。在生成时会以服务入口文件为起点通过import追踪找到所有接口注册点再从go.mod定位 proto 包提取接口定义。同时文档生成会按每类文档的规范模板写作并进行增量融合——如果服务已有文档新生成的内容会保留人工补充的业务注释只更新代码层面的事实性信息接口增删、参数变更。为了明确当前业务接口是一个线上实际在用的接口还是一个已经废弃或低频使用接口我们以接口调用量为指标在知识文档生成前查询其伽利略上的调用信息判断接口是否活跃并在文档中进行标注。另外知识库会以meta.yaml作为注册中心每个服务的文档状态、git hash记录等信息都记录在这里。skill 会根据git hash变更判断是否需要重新生成增量模式。对于全新增的知识知识库支持仓库导入模式直接从 Git URL 导入尚未纳入知识库的仓库将其 clone 到本地、生成文档、分析与现有业务域的归属关系、更新meta.yaml整个流程自动完成。3.3 知识检索渐进式加载知识的提取查询也是一个在业界经常被讨论的点现在似乎有一种共识采用层次化加载结合大模型探索的方式替代传统的 RAG 检索。之所以这种方式比传统 RAG 更适合知识库的建设是因为它复刻了人类专家查阅和学习复杂资料的真实认知习惯精准定位而非模糊匹配标准 RAG 依赖向量算相似度往往不够精确。层次化加载基于知识的真实逻辑与引用关系进行寻址能剔除无关信息避免污染大模型的上下文。自顶向下的按需吸收人类学习总是先抓框架再看细节。通过全局大纲-核心摘要-底层明细的知识金字塔让大模型顺着脉络按需加载既不会在海量长文本里迷失又能大幅节省 token。变被动查为主动探索RAG 往往是一次性被动检索而探索机制让 Agent 能像专家研究课题一样根据初步线索在知识网络里顺藤摸瓜、多步跳转自主拼凑出最精准的上下文。向量库系统维护成本高知识库天天都在更新维护一套 RAG 向量库的同步成本较高。直接依托结构化的知识本体进行探索系统架构也更加轻盈。在我们的知识库工程中同样是采用渐进式分层加载grep 的方式来实现对结构化知识的检索既能保证搜索的准确性同时又能实现按需加载节省 Token 消耗。[图片渐进式分层加载流程]当下的设计为第一层几乎总是加载文件很小通过关键词匹配缩小到 1-2 个业务域第二层用grep在meta.yaml里精确筛选避免加载整个域的服务文档第三层根据查询模式只加载必要的文档类型——接口搜索连overview.md都不读。同时提供了四种查询模式模式 A产品需求拆解。用于将 PRD 分解为可执行的后端 Story。输入是自然语言需求描述输出是output/prd-breakdown-YYYYMMDD.md包含涉及服务列表、Story 拆解用户故事格式、每个 Story 可复用的现有接口和需要新增/改造的点。模式 B技术方案拆解。用于针对具体技术目标生成技术方案文档。输出包含时序图、任务拆解表、接口调用关系、以及关键注意事项。模式 C接口搜索。最轻量的模式适合找到对应接口就行的场景。模式 D知识库问答。适用于询问业务概念、业务流程、字段含义、表结构、逻辑细节等知识性问题按需加载多个服务的文档结合custom_docs.md中的人工经验给出准确回答。对于细节性问题还可以自动下载代码进行回答。3.4 文档新鲜度检测过期知识比没有知识更危险除了生成和查询知识库工程还有一个问题便是知识更新迭代速度快已有知识容易过期。过期知识比没有知识更危险如果 AI 引入了一份过期的知识会导致由于误导性知识影响整体的流程而且往往排查起来非常困难。我们实际出现过这样一个例子在一次开发需求中让 AI 调用一个接口由于知识库没有更新AI 调用了一个老的接口整个链路都通了但是我们一直拿不到预期的结果后面花了很久的时间排查才发现是调用到了老的接口上去。对此我们引入了文档新鲜度检测任务来实现针对知识库知识的新鲜度检测。其工作原理是比较两个git hashmeta.yaml中记录的git_hash上次生成文档时的代码版本和仓库当前HEAD的hash。当差异超过阈值可配置如超过一定天数或 commit 数时该文档会被标记为过期生成任务 json然后派发 codebuddy 命令行以增量模式更新生成文档。增量模式的关键特性是最小改动原则人工批注保留增量生成会把 git diff 的内容喂给大模型同时让模型读取已有文档根据 diff 内容对已有文档进行修改尽量减少对既有文档进行大幅度改动。同时会识别其中人工添加的业务背景说明、使用示例等高价值内容在新文档中予以保留。这避免了每次更新都要重新补充上下文的重复劳动。同时添加了log.md历史保护机制确保可审计性每次生成都向log.md追加一条记录含git_hash、执行时间、变更摘要严禁覆盖历史条目。即使某次生成出错也能通过log.md结合git追溯到上次成功状态。[图片文档新鲜度检测流程]目前这套知识库工程已经覆盖了应用宝游戏后台包括活动、福利、商城、增长等在内的 4 个业务领域涵盖 90 多个微服务800份结构化文档。四、端到端开发工程建设——从写代码到交需求要突破对话式 AI Coding 的瓶颈其核心不在于模型是否足够聪明而在于将原来的开发模式从一个对话窗口升级为一套工程系统也就是现在 Harness 工程的一个核心思想。在我们的端到端开发工程中围绕 Harness Engineering 的设计思想我们主要做了几个事情拆分上下文替代单窗口累计把一个长的开发流程拆分成多个聚焦的、相对独立的子任务由单独的子 agent 来执行每个子 agent 只加载它当前所需要的信息。以状态文件替代容易被压缩的对话历史把整个开发流程中进行到了哪一步每个步骤的产出等信息持久化下来让整个执行流程具备可观测、可中断、可恢复、可协同的能力。用确定性编排替代概率性发挥把需求拆解→开发→单测→代码评审→部署→接口验证等等流程固化为按序推进、带质量验证的流水线每一步骤不达标则不往下推进把开发流程推进从靠人推动变成靠流程保证。用 DAG 多 Agent 并行替代单线程串行执行自动识别任务间的依赖关系将任务编排为 DAG 拓扑结构把同一层的任务分发给并发 agent 在隔离环境中同时开发再统一收口实现多任务的并行执行。打通从开发到提交工蜂代码全流程通过集成或者封装司内包括 TAPD、123、03、rick、伽利略、七彩石、无极等等各大平台的能力打通整个需求实现中各个环节和外部依赖。[图片端到端开发流程]4.1 状态文件驱动让流程脱离对话窗口而独立存在在对话式 AI Coding 中整个开发过程依赖对话历史来传递上下文。随着开发推进对话历史会迅速膨胀出现三个典型问题上下文有损压缩导致 AI 遗忘早期信息或偏离既定规则流程中断后无法恢复——一旦对话窗口关闭或上下文被截断之前的所有中间状态就都丢失了流程推进缺乏可观测性人和 AI 都不知道现在执行到哪一步了。要解决这些问题一个核心思路就是长链路必须状态化。把开发流程中的每一步进度、产出、依赖关系持久化到文件中让上下文脱离对话窗口独立存在。4.1.1 状态文件流程的唯一真相源整个端到端开发流程的状态被持久化在两类结构化 JSON 文件中product-state.json用于产品需求拆解后的多 Story 并行开发流程记录拆解阶段breakdown、并行分叉阶段forking、合并收口阶段joining等状态e2e-state.json用于单 Story 的端到端开发流程记录当前所处的 Phase0~7、每步的产出、接口验证结果等。每个子 Agent 在独立上下文中执行完毕后将其执行结果写入状态文件的对应字段。主调度器不依赖对话记忆而是直接读取状态文件来确定现在到哪一步了、下一步该干什么。状态文件落盘实现流程可中断、可恢复、可观测。[图片状态文件驱动流程]4.1.2 激活标志 hook 机制强制流程推进光有状态文件还不够——AI 可能在流程还没结束时偷懒停止为了进一步确保流程能够按照状态文件完整驱动执行并且每个子 Agent 在执行后能够准确地将状态和执行结果落到状态文件中我们还引入了 hook 机制通过在三个事件Stop、SessionStart、SessionEnd中注入脚本逻辑确保流程的确定性Stop Hook流程不可被主调度器偷懒式提前停止SessionStart Hook跨会话断点可自动恢复SessionEnd Hook会话结束后清理残留状态不污染下一个无关会话[图片Hook 机制示意]4.2 专家 Agent 体系每个专家只做一件事将流程拆分成多个步骤后最直接的做法是让同一个 Agent 依次执行每个步骤。但实践中发现有两个问题Agent 在角色频繁切换时行为不稳定——它可能在开发步骤里越权去修改协议也可能在审查步骤里顺手改了代码。不同步骤对模型能力的要求差异很大简单的状态解析用便宜模型即可复杂的需求拆解则需要更强的推理模型。因此我们在 Agent 层基于以下原则设计了一套专家 Agent 体系单一职责一个 Agent 只干一件事。code-reviewer 只评不改、interface-verifier 只诊断不改、code-fixer 只在收到问题清单后才动手。上下文隔离每个 Agent 在独立上下文执行只看到自己该看的输入。既避免注意力稀释也避免上游噪音污染下游判断。工具最小权限按职责裁剪工具集审查类不给写文件权限规划类不给发布权限从机制上禁止越权操作。确定性的输入输出Agent 之间不靠对话传递信息而是靠结构化状态文件。输入是明确的字段输出也是明确的字段可被脚本解析、可被断点恢复。模型可插拔职责边界清晰后每个 Agent 可独立选模型简单步骤用更便宜的模型复杂推理用更强的模型。通过角色定义 工具约束 知识隔离我们为每个阶段设计专门的专家 Agent类别Agent职责规划智能体product-analyst产品需求拆解 → N 个子需求 kb-query分析 多轮澄清 建子 story 初始化product-staterequirement-analyst需求澄清 技术方案 初始化 statetask-planner任务拆解 DAG 并发/串行编排 全局变更确认执行智能体proto-engineerRick 平台 proto 变更 桩代码同步backend-developer单任务 worktree 开发、波收口 merge、集成收口接线编译code-fixer复用型修复P4 改完只编译回归单测P7 改完编译发布验证智能体unit-testercodegen 单测 增量覆盖率interface-verifiertrpc-gateway调接口 断言 galileo 根因分析只诊断不改test-case-designer设计用例识别字段三分类审查智能体code-reviewercodar-local 评审输出 BLOCKER 清单只评不改集成智能体publisherdtools 发布 test 框架配置重启git-committer用户确认后提交工蜂 push 发起 MR其相比较于直接 call 起子 Agent 执行的方式在实践中带来了三个收益通过角色定义使 AI 执行的行为更加稳定。通过预先内置好 Prompt避免每次执行都需要主调度器临时给 Prompt 片段减少调度器的负担和抖动。便于独立维护和更新迭代可以单独修改某个专家的行为而不影响其他流程针对不同专家可以选择不同的模型来执行。4.3 从串行到并行DAG 编排 Fork-Join当一个业务需求被拆分成了若干子需求每个子需求都被拆分成多个开发任务后如果全部串行执行整个执行流程耗时会非常的长。同时主流程下积累的上下文信息也会快速膨胀。为此我们从两个维度做了优化4.3.1 Worktree 隔离同一需求内的多任务并行即使单个需求内部多个独立接口或模块之间也往往没有先后依赖完全可以同时开发。我们定义了一个task-planner的 Agent专门负责任务拆解与并发编排规划其会根据需求文档和实现方案按照接口、功能模块进行任务拆解并针对每一个任务标注其与其他任务的依赖关系以及预测需要修改的目录文件并将所有任务列表按照依赖关系构建成 DAG 拓扑分层同一层的内的任务可以并发执行。主调度器会根据task-planner返回的拆解结果进行编排并发执行的任务分配不同的worktree给到负责开发的 Agent并在本轮所有开发 Agent 执行完成后统一执行merge操作收口。[图片Worktree 隔离并行示意]4.3.2 Fork-Join多需求的并行开发与统一收口当一个产品需求涉及的逻辑非常复杂时我们往往都会先将需求拆分成多个 story 单再将每个 story 单依次完成。如果需求涉及多个人一起开发由于整个需求需要一起提测我们往往会拉一个临时分支大家把开发的代码都先往上合然后统一将这个分支发布到测试环境进行测试。这里我们的实现也类似人协作的方式在原来流程的基础上引入了一个最前置的需求拆解阶段这一阶段会结合建设的业务知识库对需求进行分析并经过与人的多轮交互澄清将一个完整的产品需求拆分成多个子需求。之后调度器会进入 Fork 并行开发阶段执行从任务拆解到代码 CR 的阶段其中拆解的多个任务仍然按照上面的流程并行开发Phase 1: 任务拆解 → Phase 2: 波次开发(并发) → Phase 3: 单元测试 → Phase 4: 代码审查当所有代码开发完成后调度器进入 Join 阶段完成后续的流程Phase R: 产品需求拆解 ↓ Fork 段并行每个子需求各自跑 Phase 1~4 ↓ Join 段串行收口合并 → 发布 → 验证 → 提交4.3.3 冲突治理事前隔离与串行收口并行不是把任务拆开就完事多个 Agent 同时修改代码不可避免会产生冲突。如果冲突处理不当会导致编译失败、代码被错误覆盖等问题冲突如何解决也是工程上的一个难题。我们对四类冲突分别制定了解决策略其核心思路就一个能事前隔离的就事前隔离必须共享的就串行收口。冲突类型策略Merge Conflict由task-planner的touches做事前的文件级隔离尽量让同批次任务不碰同一文件真发生冲突时正常解决冲突绝不用--no-verify/丢弃方式绕过Shared file(如main.go等)不在并行执行中修改统一收敛到集成收口阶段由单个 Agent 执行避免多 Agent 修改同一入口Proto 协议修改协议变更前置且串行仅当has_pb_changetrue时由proto-engineer在 Rick 平台统一变更、统一生成桩代码下游开发 Agent 基于已生成的桩代码开发DB/配置变更全局变更一次性前置确认task-planner阶段汇总落地由专门 Agent 执行避免并行更改数据库、修改配置4.4 脚本化执行确定性操作交给脚本在跑通流程之后我们复盘发现一个现象整个端到端流程中大量步骤其实是确定性操作——比如解析状态文件的 JSON、创建git worktree、执行编译命令、调用发布工具等。这些操作不需要推理只需要执行。让 AI 来做这些事不仅白白消耗了 token还引入了不必要的随机性——AI 可能写错 shell 语法、用错参数、或者在无关步骤上发散同时同一需求多次跑、不同模型跑token 消耗和结果也都可能不一致。因此我们得出一个重要结论AI 负责认知脚本负责执行。AI 的价值在于判断、分析、生成这类需要想的动作而确定性的执行操作应当交给脚本。我们将整个端到端开发流程固定的一些操作步骤流程脚本化前后沉淀了接近 15 个脚本将每个流程中一些具有明确输入输出、或者操作路径非常清晰的步骤都改为用脚本的方式来执行在消除执行流程不确定性的同时也能在这些环节省下不必要的 token 消耗状态机解析执行脚本e2e-dev.py把主调度器原本靠 AI 实现的状态文件读取解析和下一步状态确认改为通过调用脚本直接拿到对应的结果。多任务并行开发 worktree 脚本worktree.sh/sub_worktree.sh在多 Agent 并发开发同一个需求的多个任务时将git worktree相关的创建/merge/多分支集成/清理等操作都封装成脚本直接一键执行避免 AI 来回切换工作空间了解背景信息后再操作的成本。编译发布脚本build-and-publish.sh将服务编译发布抽取成一套通用的脚本将原本由 AI 按照目录探索发布脚本、或自己根据 dtool 工具说明实现编译发布的方式改为调用通用脚本一键发布。知识库一键初始化/更新脚本kb-init.sh每次或首次使用知识库进行检索前需要在本地进行初始化或更新操作。...4.5 打通最后一公里将 AI 嵌入 DevOps 全流程端到端开发的流程远不止写代码——一个需求的完整交付还涉及 TAPD 创建子需求、Rick 平台修改协议、123 平台发布服务、七彩石修改配置、伽利略查看日志等等。如果这些环节都需要人手动在不同平台之间切换操作AI 在流程中就只能起到局部加速的作用无法实现真正的端到端自动化。因此我们在工程中将公司内各平台的能力进行了系统化集成让 AI 在流程中经人工确认后可以直接完成跨平台的读写操作。4.5.1 tRPC-Gateway让本地 AI 能调通内网接口后台服务部署在 123 平台上属于内网 idc 环境但是 AI 的执行是在本地电脑上。如何实现 idc 环境调用这个问题也困扰了我们针对每个服务都申请白名单的方式显然不够通用。4.5.2 CodarAI 写的代码让 AI 来审AI 自身缺乏全局视角对结合业务逻辑边界的隐含 bug 识别能力弱。对此一种比较直接的方式是自己沉淀一套与业务逻辑相关的 CR 规则集并随着业务的迭代持续更新其中的规则信息。但在活动平台系统重构之初我们团队就和 Codar 团队进行了合作在代码 MR 环节引入了 Codar 团队的 CR 流水线实践下来我们发现 Codar 对代码隐含的业务逻辑漏洞的识别能力非常不错因此我们和 Codar 团队进一步合作集成了 Codar CR skill 到我们的 CR 步骤中。CR 环节AI 除了会根据现有的代码规范对代码进行 CR 外还会通过 Codar 提供的 CLI 工具对增量代码进行 CR并将 CR 出来的问题和风险级别返回给主调度器由 Fix Agent 针对问题进行修改。4.5.3 多平台读写集成在一个需求的开发流程中涉及 TAPD 平台创建子需求单、Rick 平台更新协议、123 发布服务、七彩石修改配置、伽利略监控等等。目前来说大部分平台都提供了相应的 MCP 服务或者 Skill来实现 AI 集成基本也可以在公司 Knot 平台 还有 03 平台 上找到这些功能。目前我们的端到端开发工程也都基本集成了上述平台的能力AI 在整个开发流程中经人工确认后可以直接在相应的平台上执行读取/写入操作。不过这里有一个例外123 平台上现在默认的业务配置嵌入的配置页面走的是七彩石的 tconf 集群但七彩石的 mcp 并没有支持 tconf 集群。因此很多服务如果是直接在 123 平台业务配置这里新增配置是没有办法走七彩石的 mcp 来实现服务配置的读取和写入的。五、复盘、规划与思考5.1 实践复盘核心工程原则在我们团队的工程实践中经过多轮调试与架构演进总结出以下核心经验与优化建议应对异构服务拓扑构建目录解析抽象层实际业务中的代码组织形式复杂多样涵盖单仓单服务Multi-repo、单仓多独立服务目录以及共享go.mod与底层公共包但具备多main.go入口的 Monorepo 架构。直接依赖 Agent Skill 来兼容这些异构拓扑会成倍放大调试成本。建议在工程架构初期优先建立统一的目录解析抽象层以标准化后续的处理流程。调度架构演进从 Agent 驱动转向强类型代码编排早期我们团队在基于 Claude 与 Skill 机制构建更新流时就已经发现存在指令依从性不足的隐患。为控制成本引入 hy3-preview 后进一步暴露出流程失控如子 Agent 越界接管主链路及调试周期过长等工程痛点。为此我们在知识库工程上优先做了两个调整弃用主子 Agent 模式改由外部主程序编排全局流程。通过代码直接调度 Codebuddy CLI实现职责解耦hy3-preview 专注于局部服务文档的生成Claude 则负责高维度的域Domain及全局架构综述。弃用 Shell 脚本测试的时候发现大模型生成的 Shell 脚本常潜藏隐性语法错误或边界逻辑漏洞且往往在长链路末端才抛出异常极耗排查时间。最终将驱动层全面重构为 Go 代码利用强类型语言的特性来保障执行控制流的严密性与稳定性。严格禁用项目级 Memory 以保障状态隔离全局 Memory记忆机制会引入不可控的上下文串扰导致 Agent 偏离既定职责如越界干扰主流程并严重破坏单一子任务的幂等性与可复现性。在构建强确定性的自动化流程时必须彻底关闭该功能以维持每次任务上下文的纯粹性。引入 Mock 机制分离调度逻辑与生成耗时自动化构建流水线主要由流程调度与文档生成构成。其中调度逻辑最为复杂而生成任务耗时最长。及早在工程中引入 Mock 机制通过模拟或跳过大模型的实际生成环节能够以极低的成本快速验证、迭代调度链路大幅提升整体联调效率。如果说上面这些是具体场景下的经验那么把它们再往上抽象一层我们沉淀出了几条贯穿整套 Harness 工程的核心原则——它们既是前面所有设计的出发点也是我们判断一个环节该不该这么做的准绳AI 负责认知脚本负责执行——工程的核心思想长链路必须状态化——状态脱离上下文落盘才能稳定续传知识库必须结构化——业务知识结构化AI 才能精准检索Agent 必须职责隔离——单一职责、上下文隔离、最小权限执行步骤必须脚本化——执行问题不要交给推理Workflow 比 Prompt 更重要——流程编排的确定性胜过反复打磨 prompt终局认知未来比拼的不是用了多少 AI而是能否把 AI 当作一个工程系统来设计5.2 下一步从能跑到跑得好目前来说对于这套 Harness 工程仅仅处于能跑的刚起步状况在很多地方、细节方面还有待完善和改进缺少自我复盘迭代的自进化能力每次跑完一个流程后依赖人工发现并修复流程中的问题。缺乏一套完善的评估体系来评估整个 AI 端到端开发流程的稳定性、开发效果、token 成本消耗等等。整套体系重度依赖于 codebuddy cli 工具来运行还没有实现工程与工具的解耦。...最近Claude 发布的 Workflow 模式也给我们带来了新的启发团队也正在尝试将流程编排引入到这套工程实践中将这套工程由原来 AI 自己根据状态文件实现流程串联必要时由 AI call 起脚本调用的流程改为由脚本实现流程串联必要时由脚本 call 起 AI 调用的方式来实现。至于说到底哪种方式才是业界的标准答案目前也没有定论大家都在摸索但方向是一致的——让确定性的归脚本让认知的归 AI[图片脚本与 AI 分工]5.3 一些开放性思考5.3.1 TDD 在 AI 时代先写测试还是先写代码TDD 是软件工程中令人向往的开发模式但在实际代码开发中践行很难——接口字段、校验规则、依赖接口甚至很多业务逻辑往往都要等代码和协议落地后才能确定提前写单测极易返工。因此在我们的实践中TDD 的落地不在代码层面而是集中在接口测试用例上在一开始的需求方案设计环节便会根据需求生成一份需求级测试用例包含输入输出的预期。在流程后面的请求验证环节便会基于这份测试用例构造对应的请求并针对结果判断是否符合用例预期。5.3.2 AI 工程的架构分层我们缺的不只是好 Agent还有好架构传统软件工程中代码如何组织架构如何设计业界有着非常多非常成熟的方法论MVC、DDD、Clean Architecture 等等。但是对于 AI 工程架构上如何设计Agent、Skill 之间如何组织AI 工程与 AI 工具如何解耦Agent 与 Skill 如何插拔式组合等等当下似乎并没有看到什么很成熟的方法论或实践规范更多的都是结合 Code 工具的规范定义一个 skill 目录一个 agent 目录然后就都往里加。当下我们这套工程中的组织方式也有着同样的问题。工程与工具的解耦、Agent/Skill 的分层与插拔式组合是后续要重点优化的方向。5.3.3 代码还重要吗——从代码为王到架构为王在 AI 生产代码效率越来越高的当下有一种说法是忘记代码的存在人不再逐行审查 AI 写的代码只关心运行结果是否符合预期。YouTube 上有一个来自 Anthropic 研究员的演讲分享的就是这种观点Vibe coding in prod但是我们所面对的并不是一个工具系统而是一个涉及多微服务、调用链路复杂、有着高并发、高性能要求的复杂在线业务系统就现阶段来说我认为保持高质量的代码架构依旧非常重要ai 代码腐化速度非常快哪怕是现在 Claude Opus 4.8放任迭代会很快偏离既定的规范。高质量的代码和架构会反哺 AI让 AI 生成的代码质量更高这是一个正反馈的过程。一旦人对代码失去掌控线上出问题就只能完全靠 AI 排查定位。但不能否认这个观点的前瞻性在我们团队内部也有类似的实践重构后的活动平台系统在 With 平台搭建了一套统一的集成看板集成了包括在线活动一览/活动实时参与情况监控/活动消耗实时监控/活动诊断/活动复盘等能力实现从事前到事后的全活动生命周期一站式运营。这套看板代码 100% 由 AI 通过对话式 Vibe Coding 生成没有一个人去 CR 过它的代码前端/后台/产品/运营任何一个同学只要有任何活动看板的需求都可以在这上面通过对话的方式集成。[图片集成看板示例]这其中的区别在于看板这类结果导向、容错率高、无强一致性要求的系统适合黑盒化而核心在线业务系统现阶段仍需要人守住架构这条线。而这条线或许也会随着 AI 的进化不断后撤或许终有一天代码会像汇编语言那样从开发者手中精心雕琢的核心资产退场为智能体之间无声流动的中间表达——被生成被消费却不再被凝视。从逐行审查到忘记代码变化的从来不是代码的价值而是人在系统中的位置。这条边界还会继续移动而我们能做的是始终想清楚此刻人究竟该站在哪一侧。