我的研发实践：高准确率 AICoding 工作流设计

痛点分析

▐  模型能力调研

• Claude4模型

目前编程圈中最火爆的应当是由Anthropic开发的Claude 4模型，该模型具备了混合推理能力和强上下文能力，兼具即时响应与深度思考两种模式，并可以根据任务需求在两种模式间切换：

• Claude Sonnet 4 系列模型具备强大的工具使用能力，兼顾效率与能力提升

• Claude Opus 4 特别在记忆能力上有重大突破，对长时间任务的场景中有稳定的发挥

基于Claude4 模型的全新终端AI编程工具ClaudeCode，可以通过自然语言指令帮助开发者高效率地完成代码编写、调试和项目管理任务。它直接集成在开发者的工作环境（如终端）中，无需依赖额外服务器或复杂配置即可运行。

实际使用下来，ClaudeCode能够在复杂推理任务中表现出色，同时保持交互体验的流畅性。随着Claude Code的爆火出圈，这个产品是真实地提高程序员的开发效率。但是随着Cursor、Claude Code对国内ip加大力度管控，使用这类前沿工具变得十分困难，国内的程序员不得不投向更多的国产模型。

• QwenCoder模型

最近一个月也迎来了很多惊喜：Kimi K2、Qwen3-Coder、GLM-4.5 等国产大模型相继涌现。国产编程工具正不断突破创新，致力于为国内开发者打造更智能、更高效的极致开发体验。Moonshot AI刚在11号发布了旗舰模型Kimi-K2-Instruct；通义千问就在22号发布了Qwen3-235B-A22B的非思考模式版本——Qwen3-235B-A22B-Instruct-2507；紧接着，23号又立马推出了通义迄今为止最具代码能力的代码模型Qwen3-Coder，甚至还在下班后搞“突袭”，发布了思维和推理能力更强的Qwen3-235B-A22B-Thinking-2507。

SWE-bench Verified检查了模型们解决实际代码问题的能力，看起来Qwen3-Coder略胜一筹，整体能力可与Claude Sonnet 4 （得分70.4%）媲美。如此分析，在BUG修复或功能实现类任务中，Qwen3-Coder效果会更好一些，尤其是在代理编码任务上。不过虽然Qwen3-Coder在“纸面成绩”上更强，但实际开发中遇到的困难可能与测试完全不同。

总体来看，Qwen3-Coder 在短期任务中表现出色，对项目需求的理解较为完整，适合生成逻辑复杂、效率要求高的代码。但在大型生产环境中，其稳定性与扩展能力略显不足。相比之下，Kimi-K2 表现更为稳健，擅长将复杂任务拆解为子任务逐步执行，生成的代码可读性和可用性都很高。每种模型都有其优势与局限，关键在于根据实际场景选择合适的工具。如果追求可控性、高效率和输出质量，Kimi-K2 是更优选择；而若侧重复杂逻辑建模与高效编码，Qwen3-Coder 则更具优势。

从准确率的角度来说，Claude4无疑是最佳的选择，但鉴于对于公司C3级别代码仓库的安全考虑，我们应该使用Qwen3-Coder作为高安全级别的仓库的兜底选择。

▐  CodeAgent选择

Agent就是AI作用于互联网的软件形态产品。如果说PC时代是网站，手机时代是APP，那AI时代就是Agent。所有的领域，所有的应用，可能都会被AI通过Agent革新一遍。下图展示开源的CodingAgent应用可以说是百花齐放：

Agent 正在迅速普及，似乎正在取代我们熟悉的Chatbot，那么我们平时工作已经或多或少的使用的CodeAgent究竟是什么？

• 什么是LLMAgent

它其实本质上是增强型LLM Agent的一种实现。要理解 LLM Agent 是什么，让我们先回顾一下 LLM 的基本能力。传统上，LLM 最基本的功能只是预测下一个 token。

最基本的就是通过连续采样多个 token，我们可以模拟对话，并让 LLM 对我们的查询给出更长的回答。

然而，仅仅有LLM的能力是否就能称为Agent呢？并不能！比如当我们继续进行“对话”时，它不记得之前的对话！

这也是为什么LLM的Agent都会有基于记忆产生知识库的产物：如Rules、Docs、记忆、Wiki，加上记忆以后，我们可以称之为Copilot了，但是Agent的定义是需要根据用户的指令产出完整的方案或者代码。比如，LLM在很多其他任务上如乘除法、git命令、代码仓库检索等方面表现不佳：

这时候就需要通过外部git工具、wiki记忆和code检索系统来弥补它们的不足。通过外部系统，LLM 的能力可以得到增强。Anthropic 公司将这称为“增强型 LLM”（Augmented LLM）。例如：我们日常使用到的CodeAgent，就是封装了很多基于codebase能力引入的工具。

这些工具能力不仅CodeAgent之间可以互相调用，也可以封装成mcp服务，直接被外部系统调用。

通过规划、记忆、工具的补充是不是增强型的LLM是不是我们上面看到CodeAgent，还不完全是！

根据  Russell & Norvig, AI: A Modern Approach (2016) 文献显示：

Agent 的准确定义可以被看作是能够通过传感器感知环境，并通过执行器对环境采取行动的任何事物。

完整的Agent 与需要与环境进行互动，以CodeAgent举例，通常包含几个重要组件：

• 环境 (Environments) — 仓库上下文，@Codebase

• 传感器 (Sensors) — 游标cursor，定位所需修改代码的位置

• 执行器 (Actuators) — @grep_search @search_replace 工具

• 效应器 (Effectors) — 大模型本身所具备的 Planning & Relection

具备LLM的决策规划能力，并能够通过传感器感知环境，并记录历史上下文信息，并通过执行器使用工具对环境采取行动的代理，可称为完整的agent。

• Agent的决策逻辑

Agent的核心决策逻辑是让LLM根据动态变化的环境信息选择执行具体的行动或者对结果作出判断，并影响环境，通过多轮迭代重复执行上述步骤，直到完成目标。

精简的决策流程：P（感知）→ P（规划）→ A（行动）以我们所依赖的CodeAgent举例：

1. 感知（Perception）从上下文、wiki、Rules、记忆获取提取相关知识的能力。

2. 规划（Planning）是指Agent为了某一目标而作出的决策过程，复杂场景会以待办任务的进行罗列。

3. 行动（Action）是指基于环境和规划做出的最终的Action：如修改代码、编译、单元测试等。

其中，Policy是Agent做出Action的核心决策，而行动又通过观察（Observation）成为进一步Perception的前提和基础，形成自主地闭环学习过程。工程实现上可以拆分出四大块核心模块：推理、记忆、工具、行动。

影响模型最终结果的是决策模型的框架，目前Agent主流的决策模型是ReAct框架，也有一些ReAct的变种框架，以下是两种框架的对比。

• 传统 Reason and Act

ReAct=少样本prompt + Thought + Action + Observation 。是调用工具、推理和规划时常用的prompt结构，先推理再执行，根据环境来执行具体的action，并给出思考过程Thought。

• Plan-and-Execute ReAct

一部分Agent通过优化规划和任务执行的流程来完成复杂任务的拆解，将复杂的任务拆解成多个子任务，再依次/批量执行。优点是对于解决复杂任务、需要调用多个工具时，也只需要调用三次大模型，而不是每次工具调用都要调大模型。缺点也显而易见，在简单任务中需要额外的进行规划和拆解需要更多的耗时。

基于以上的分析，我们的目前阶段工作流模型只需基于ReAct模型即可完成我们预期的诉求。

• Agent常见框架

在Agent框架选择上，一般我们在IDE或者cli中直接使用的都是单一Agent，单一LLMAgent可以通过工具、记忆、规划执行，很好的完成我们诸如：代码变更的诉求，如果我们的工作流有且仅有代码修改时，这样的架构无疑是最高效的，但是，我们也必须看到单一 Agent 有几个问题：工具太多可能导致选择复杂，上下文变得过于庞大，以及任务可能需要专业化。

如交易场景：不同业务领域的Agent所需要的上下文是完全隔离的，同时不同场景Agent在完整需求交付链路上所扮演的角色也完全不同，因此，我们对于未来的设计规划可以转向多 Agent，这是一种框架，其中多个 Agent（每个 Agent 都具有工具、记忆和规划能力）相互之间以及与环境互动：

结合我们现有工作流的场景，CodingAgent除了代码修改以外，虽然也可以做如变更创建、分支创建、CR创建等等MCP工具的使用，但是实际体验来说，使用一个前置代理Agent可以更快捷、高效、低消耗的完成同样的事情。未来，当知识库、规范足够大时，Multi-Agent更能凸显出对于特定领域记忆和上下文窗口的适配性。

但Multi-Agent更多还是为了解决当前LLM的能力上缺陷，通过LLM多次迭代、弥补一些显而易见的错误的过渡产物，不同框架间仍然存在着极高的学习和开发成本。始终相信一个技术的价值，不在于你的方案有多先进，框架有多厉害，而是是否可以更好的满足业务的需求，创造出业务独有的范式，即使我们把现在的问题放大十倍，也会发现很多事都不是现在该关心的事。在当前阶段我们选这个Single-Agent框架 + 前置代理Agent就可以完成全部的诉求。

▐  协议选择

技术的目的是帮助业务解决问题，我们要非常清楚我们问题的定性，选择最合适的技术。

• MCP协议 - 智能体与工具通信

Anthropic是一家成立于2021年的人工智能初创公司，由OpenAI的前研究副总裁Dario Amodei和GPT-3论文的一作Tom Brown等人共同创立。该公司非常有名的产品是大模型-Claude。24 年11月，Anthropic推出MCP 协议，并在自家的 Claude 客户端做了支持。后续各大模型公司纷纷开始支持MCP协议。

从上面的动图我们可以看出，完整的MCP架构由三部分组成：

• Host 是集成AI工具数据的应用平台（如豆包APP），托管Client并提供AI任务执行环境；

• Client作为通信中介，管理Host与多Server间的请求响应、通知处理和性能采样；

• Server提供三大核心能力。

• 工具模块调用外部API简化服务交互；

• 资源模块打通数据库实现数据驱动决策；

• 提示词模块通过模板化指令优化AI工作流程。

• A2A协议 - 异步执行

我们编码需求实现的过程中，需要和 DevStudioAgent、AoneAgent等专职负责代码修改的CodingAgent进行通信，同时，在特定场景中又需要和相关CodingAgent底层提供的SandBox的MCP编码工具进行直接交互，最后实现我们的完整诉求。

那我们Agent之间应该如何通信呢？答案就是A2A协议，Agent2Agent（A2A）是 Google 推出的一个开放通信协议，专为多个 AI Agent 之间的协作而设计。它允许来自不同平台、不同厂商的智能体像人类一样进行对话、协商、分工与协作，从而共同完成复杂任务。你可以将它类比为网页世界的 HTTP 协议——A2A 是 AI 代理之间的“通用语言”。

A2A 的核心目标是构建一个“智能协同体”（Intelligent Collective），让多个 Agent 像流水线一样协同工作，提升任务执行效率与智能系统的整体表现。虽然 A2A 与此前 Anthropic 提出的 MCP有相似之处，但两者的定位和功能存在明显差异，简而言之，MCP 更像是“Agent 与工具”的接口，而 A2A 是“Agent 与 Agent”的协作协议。

• AG-UI协议 - 实时展示

考虑到服务端在执行工作流的任务时，是一个相对比较长的过程。如何让用户在工作流处理的过程中实时感知到整体的进度？如何让模型规划（Planing）的过程，模型使用工具执行操作的过程变得可视化？用户与这些智能体之间的互动是否有统一的标准？答案：有！那就是AG-UI（Agent-User Interaction Protocol）协议，AG-UI 是由 CopilotKit 发布的开放、轻量、基于事件的协议，通过标准 HTTP 或可选的二进制通道，以流式方式传输 JSON 事件。它主要用于标准化 AI 智能体与前端应用程序的交互，确保实时同步和高效通信。

AG-UI 的出现，为用户与智能体之间的互动提供了标准，优化了用户体验。AG-UI 定义了一套小而强的事件类型集合，以 JSON 对象形式进行传输。以下为核心类型及结构说明：

这个特性，使得AG-UI协议特别适合于多轮协同智能体系统（Multi-Agent Copilot）的页面表达的开发：

• AG-UI 与 Agent runtime（如 LangGraph）协同，管理上下文和 UI 状态

• 支持长任务生命周期、思考中状态提示、功能建议列表

▐  完整生态

AG-UI 与 MCP（Model Context Protocol）和 A2A（Agent-to-Agent）协议共同构建了完整的 AI 代理生态系统：

• MCP：解决智能体与工具之间的通信。

• A2A：规范智能体之间的协作。

• AG-UI：专注于用户与智能体之间的互动。

目标确定

▐  从AB实验下线推全这个轮子造起

• 什么是一休AB实验

没使用过相关平台可能还是不太理解。简单来说，就是通过分流以后的分组对比确定功能的效果。

对于研发人员来说，就是调用一休的sdk，一休的结果告诉我用户在哪个组，然后业务逻辑走不同的分支：

• 什么是实验下线推全

产品层面已经决定下线或者推全对某个模块的实验功能了，在代码中，还残留的代码分支，不易于理解代码，需要结合相关信息才能推测目前的分支走向，这时候研发需要从编码上进行清理，以保证代码逻辑不腐化。

既然有了目标和思路，那第一个想法是首先要把这个AB实验下线推全的工作流的轮子给造出来，麻雀虽小，五脏俱全。说干就干，为此，我们完整分析了基于AB实验下线推全生码的工作流所需要的依赖，那基于业务场景需求，我们建了计划构建一套以A2A协议到AG-UI协议转换为枢纽，结合业务知识动态提示词为核心的的AI智能生码系统：

交易生码整体架构

该系统采用分层架构设计，确保系统的可扩展性和稳定性，基于此架构，我们目前需实现 AB实验下线推全 的完整自动化生码流程。系统的核心运行流程包括：

• 前端交互层：工作流配置获取、WebSocket连接建立、AG-UI协议传输，实现生成式UI动态展示；

• 中间服务层：IDE空间管理（HTTP加密接口）、AB实验平台集成（HSF接口查询）；

• 工具集成层：Aone变更和Code分支创建（MCP工具集成）、A2A协议配置传输（事件处理机制）；

• 数据回写层：实验治理平台集成（HSF回调）。

▐  模块编排

要实现相关工作流的运行，需将整体架构拆分为三个关键模块：A2A协议转换、AG-UI协议通信和Workflow编排引擎模块。

其中A2A模块承担AI代理通信的桥梁职责，实现了流式响应处理和JSON-RPC消息协议的标准化封装。AG-UI服务通过WebSocketService与后端建立实时通信链路，结合前端Next.js框架，实现即时生成式UI的动态渲染效果。Workflow编排引擎负责协调MCP工具链、Diamond配置中心、内部平台服务，通过TaskManager统一管理任务状态，实现工作流的可视化运行监控。

• 运行流程

典型的工作流执行遵循以下标准化流程：

1. 配置初始化阶段：前端应用调用GET /complete接口获取工作流配置信息

2. 工作流启动阶段：前端发送POST /start-workflow请求启动工作流，携带实验业务参数

3. AI代理执行阶段：Tagent执行核心AI代理任务，包括数据处理和业务逻辑执行

• 通过POST /a2a向A2A服务发送策略增强和prompt任务请求

• 调用MCP工具执行具体操作（createBranch、searchCode等标准工具调用）

• 与内部AB实验平台进行数据交互，获取实验配置信息

• 向TCS系统发起合并请求，完成代码集成

• 定义工作流

在工作流体系建设过程中，为了增强后续能力扩展性和整体系统开放性，我们对核心流程进行了深度抽象和标准化固化，成功沉淀了一套AB实验下线与Switch开关切流的标准化工作流配置体系。

# 工作流元数据配置
metadata:
  name: "AB实验下线工作流"
  version: "2.1.0"
  description: "AB实验下线和代码注释工作流"
  totalSteps: 5 

# 步骤配置 (前端显示用)
steps:
  - id: 1
    title: "创建IDE空间"
    description: "后续的代码操作基于此IDE空间"
    icon: "monitor"
  - id: 2
    title: "获取AB实验"
    description: "获取AB实验的详细信息"
    icon: "database"
  - id: 3
    title: "创建变更"
    description: "创建Aone变更请求"
    icon: "git-branch"
  - id: 4
    title: "代码修改"
    description: "统一处理AB实验相关的所有代码修改"
    icon: "code"
  - id: 5
    title: "创建代码评审"
    description: "创建CR，并回调TCS平台写入相关信息"
    icon: "upload"
# 卡片生成配置
cardGeneration:
  rules:
    # 步骤1: 创建IDE空间
    step1:
      type: "link"
      title: "IDE工作空间"
      template: "{workspaceUrl}"
      action: "open"
    # 步骤2: 获取AB实验信息  
    step2:
      type: "cards"
      title: "AB实验信息"
      template: "**实验名称**：{expName}\n**目标分组**：{expGroup}\n"
      action: "copy"
    # 步骤3: 创建变更和分支
    step3:
      type: "text"
      title: "分支信息"
      template: "分支: {branchName}"
      action: "copy"
    # 步骤4: 代码修改 - 工作流信息一览格式
    step4:
      type: "cards"
      title: "大模型修改总结"
      template: "{desc}"
      action: "copy"
      autoCollapse: true  # 第四步完成后自动收起
    # 步骤5: 创建代码评审
    step5:
      type: "link"
      title: "代码合并请求"
      icon: "upload"
      action: "open"

# Trade Agent Switch开关治理工作流配置文件
# 版本: 1.0.0
# 用于统一管理Switch开关治理工作流步骤和卡片生成等

# 工作流元数据配置
metadata:
  name: "Switch开关治理工作流"
  version: "1.0.0"
  description: "智能开关治理工作流，支持开关状态管理和代码自动化修改"
  totalSteps: 5  # 步骤1-5：IDE空间、获取开关信息、创建变更和分支、代码修改、创建代码评审
  author: "Trade Agent Team"
  lastModified: "2025-01-18"
# 步骤配置 (前端显示用)
steps:
  - id: 1
    title: "获取开关信息"
    shortTitle: "开关信息"
    description: "获取Switch开关的代码定义和引用仓库"
    icon: "toggle-left"
    category: "experiment"
  - id: 2
    title: "创建IDE空间"
    shortTitle: "IDE空间"
    description: "后续的代码操作基于此IDE空间"
    icon: "monitor"
    category: "setup"
  - id: 3
    title: "创建变更"
    shortTitle: "变更分支"
    description: "创建Aone变更请求"
    icon: "git-branch"
    category: "branch"
  - id: 4
    title: "代码修改"
    shortTitle: "代码修改"
    description: "AI自主修改代码并提交，耗时3到5分钟"
    icon: "code"
    category: "coding"
  - id: 5
    title: "创建代码评审"
    shortTitle: "代码评审"
    description: "创建CR，并回调Switch平台写入信息"
    icon: "upload"
    category: "review"
# 卡片生成配置
cardGeneration:
  rules:
    # 步骤1: 获取开关信息
    step1:
      type: "cards"
      title: "Switch开关信息"
      template: "**开关名称**：{switchName}\n**应用名称**：{appName}\n**操作类型**：{switchAction}"
      icon: "toggle-left"
      action: "copy"
      category: "experiment"
    # 步骤2: 创建IDE空间
    step2:
      type: "link"
      title: "IDE工作空间"
      template: "{workspaceUrl}"
      icon: "monitor"
      action: "open"
      category: "setup"
    # 步骤3: 创建变更和分支
    step3:
      type: "text"
      title: "分支信息"
      template: "分支: {branchName}"
      icon: "git-branch"
      action: "copy"
      category: "branch"
    # 步骤4: 代码修改 - 工作流信息一览格式
    step4:
      type: "cards"
      title: "工作流信息一览"
      cardTitle: "开关治理修改总结"
      template: "{desc}"
      icon: "code"
      action: "copy"
      category: "coding"
      autoCollapse: true  # 第四步完成后自动收起
    # 步骤5: 创建代码评审
    step5:
      type: "link"
      title: "代码合并请求"
      template: "{crUrl}"
      icon: "upload"
      action: "open"
      category: "review"
# 参数配置
parameters:
  # 必需参数
  required: ["switchName", "appName", "id", "taskId"]
  # 默认参数
  defaults:
    branchPrefix: "ai_switch_"
    template: "devstudio-remote-agent"
    callSystem: "switch"

▐  提示词设计

而对于我们一休实验自动下线，提示词的设计上有啥思路呢？自己也是一个业务开发，对一休ab使用的比较多，也就有一些理解。deepseek的深度思考不是可以对提示词优化嘛，因此我先写了一份我想做的事情，让ai帮我生成一份非常好的提示词。再仔细思考下，还需要加上（推全的组 + 一休实验的key + 一休实验的数据  + 提示词指引）这些动态信息，agent才能帮我准确实现一个实验下线了，下图的执行流程，和人类实现实验下线类似，将其抽象为提示词给agent理解：

• 什么是好的提示词

如何写好提示词呢？参考了业界对于好的提示的定义标准和规范

经过多版的思考迭代，提示词内容框架拆分成全局Rule和执行时提示词， 设计如下：

可以看到“一休的实验数据”是放置在提示词上下文，其实也可以提供MCP的工具由agent自己决定调用。不过一休实验数据调用是一步很明确的动作，直接放置上下文中也是一种方式。