高准确率AI编程工作流的设计与实践本文探讨了企业研发中 AI 编程工作流设计，通过 MCP 和 Agentic 工作流分

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

从氛围编程说起

根据 2025 年度《DevData 研发效能基准报告》指出：主观数据中部分企业反映应用 LLM 后效率有中高幅度提升，客观数据显示已落地应用 LLM 的企业代码生产率中位值较未应用企业有明显增幅，二者相互呼应，凸显 LLM 对代码产出效率提升的实际价值：

从上图可以看出：应用 AI 的团队效率确实有提升，代码生产率中位数提升了 17%。但在质量方面，约 40% 的企业反馈 AI “效果不明显”，说明其在处理有复杂依赖和知识的质量保证工作时仍面临挑战。这部分反映的依然是 LLM 应用在企业领域上研发提效的实际场景。「Vibe Coding」氛围编程如火如荼，但是企业研发提效上效果和质量都还没有标准化的范式，在研发团队提效在全民 AI 时代，我们能做什么，能做到什么程度，在成本日益收紧的今天，如何驱动团队以更高效能交付更高质量的产品？

应该从哪里入手

对于GenAI在软件领域落地的Framework不难看出，我们业务工程提效领域的突破点，应该选在原来你做的就很好的领域，在可控的范围内去做提效；同时沉淀经验模版，利用它去做学习，学习以前学不来的部分；

哪些是可以突破的点呢？首先需要明确的是如果一个问题在舒适区里没遇到任何困难，说明价值不大，一个问题走出了舒适区很远才走通，回过头来看，可能是你迷路了进入了危险区。所以在AI的时代，当迷茫时就应回到原点，或者退一步再思考。我们要找到解决问题的最短路径，才是整个刨根问底、追根溯源过程中最有价值的一环。

也许答案就在身边

我们认为新需求的「Vibe Coding」氛围编程，主要依赖于大模型的能力，我们在不依赖于业务场景的需求提示词工程完成过程中，可能今天我们做的优化，在明天就成为了大模型本身结合RAG进行反馈纠偏的能力，这种场景称之为业务场景的浅水区，属于低价值领域。

同样，想在目前的上下文窗口限制下，完整实现在需求的规划、分解、执行全流程完成端到端上线发布到生产环境的场景，属于业务的深水区，复杂性高，属于危险区域

资源总是有限的，我们要学会控制自己的欲望，我们要清楚时间最终花在哪儿，结果就会在哪儿

我们认为只有业务和通用能力的双重建设，选取足够细分的场景，只要一件小事情的能被90%正确性以上的解决，那这个方案我们认为是可被接受、安全且具有推广价值的AI提效途径。

痛点分析

通用MCP能力基座为基础，集合业务问题场景所需的工作流步骤和上下文，实现精确到点需求发布，是我这次选择的目标，在AI大模型的实践红海中，需要以最快速度拆解出目标完结的最小闭环。

工作流的设计

MCP workflow

以通用场景的查股票（查股票然后邮件通知）来进行举例：

智能体通过Client获取各Server注册的工具清单。
用户提出"查股价+邮件通知"复合需求触发任务。
大模型解析语义后联动选择股票接口和邮件工具。
Client将工具调用指令路由至对应功能Server。
Server异步执行API查询及邮件推送操作。
执行结果经Client回调至智能体完成服务闭环。

Agentic workflow

Workflow 最终会成为一个组件被调用，同时 workflow 中又能够嵌套新的workflow，实际上不管是基础节点、插件工具、LLM、逻辑条件处理等，都实际上是一个以输入、输出的组装的模块，不同的组件之间通过连接构成一个更大的模块。基于独立的输入输出的模块，结合起来，在每个域都可以独立成完整的工作，这样可以构建更复杂的需求实现。

模型能力调研

Claude4 模型

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

Claude Sonnet 4 系列模型具备强大的工具使用能力，兼顾效率与能力提升
Claude Opus 4 特别在记忆能力上有重大突破，对长时间任务的场景中有稳定的发

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

随着Cursor、Claude Code对国内ip加大力度管控，使用这类前沿工具变得十分困难，国内的程序员不得不投向更多的国产模型。

QwenCoder模型

Kimi K2、Qwen3-Coder、GLM-4.5 等国产大模型相继涌现。国产编程工具正不断突破创新，致力于为国内开发者打造更智能、更高效的极致开发体验。

模型名称	总参数量	上下文长度	SWE-bench Verified	LiveBench (Average)	备注
Kimi-K2-Instruct	1T	128K	65.4%	Coding 71.78% Agentic Coding 20%	数学推理强 NMLU 89.5%
Qwen3-Coder	480B	1M	69.6%	Coding 73.19%Agentic Coding 25%	原生256K上下文可拓展至1M

如果追求可控性、高效率和输出质量，Kimi-K2 是更优选择

若侧重复杂逻辑建模与高效编码，Qwen3-Coder 则更具优势

CodeAgent选择

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

e2b-dev/awesome-ai-agents: A list of AI autonomous agents

什么是LLMAgent

LLM 就是通过连续采样多个 token，可以模拟对话，并让 LLM 对我们的查询给出更长的回答。但是继续进行“对话”时，它不记得之前的对话！

这也是为什么LLM的Agent都会有基于记忆产生知识库的产物：如 Rules、Docs、记忆、Wiki，加上记忆以后，我们可以称之为 Copilot 了

LLM 在很多其他任务上如乘除法、git命令、代码仓库检索等方面表现不佳：这时候就需要通过外部 git工具、wiki记忆和 code 检索系统来弥补它们的不足。通过外部系统，LLM 的能力可以得到增强。

Anthropic 公司将这称为“增强型 LLM”（Augmented LLM）。

CodeAgent，就是封装了很多基于 codebase 能力引入的工具。这些工具能力不仅CodeAgent 之间可以互相调用，也可以封装成mcp服务，直接被外部系统调用。

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

环境 (Environments) — 仓库上下文，@Codebase
传感器 (Sensors) — 游标cursor，定位所需修改代码的位置
执行器 (Actuators) — @grep_search @search_replace 工具
效应器 (Effectors) — 大模型本身所具备的 Planning & Relection

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

Agent的决策逻辑

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

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

感知（Perception）从上下文、wiki、Rules、记忆获取提取相关知识的能力。
规划（Planning）是指Agent为了某一目标而作出的决策过程，复杂场景会以待办任务的进行罗列。
行动（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通过优化规划和任务执行的流程来完成复杂任务的拆解，将复杂的任务拆解成多个子任务，再依次/批量执行。优点是对于解决复杂任务、需要调用多个工具时，也只需要调用三次大模型，而不是每次工具调用都要调大模型。缺点也显而易见，在简单任务中需要额外的进行规划和拆解需要更多的耗时。

Agent常见框架

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

多智能体优点：

复杂问题拆解：每个子agent负责解决特定领域的问题，降低对记忆和prompt长度的要求；
开闭原则：通过增加子agent来扩展功能，解决单agent并发的问题
可操控性强：可以自主的选择需要的视角和人设更快的解决问题

缺点：

成本和耗时的增加；
交互更复杂、定制开发成本高；
简单的问题单Agent也能解决；

Multi-Agent 不同框架间仍然存在着极高的学习和开发成本。始终相信一个技术的价值，不在于你的方案有多先进，框架有多厉害，而是是否可以更好的满足业务的需求，创造出业务独有的范式，即使我们把现在的问题放大十倍，也会发现很多事都不是现在该关心的事。

协议选择

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

24 年11月，Anthropic推出MCP 协议，并在自家的 Claude 客户端做了支持。后续各大模型公司纷纷开始支持MCP协议。

完整的MCP架构由三部分组成：

Host 是集成AI工具数据的应用平台（如豆包APP），托管Client并提供AI任务执行环境；
Client作为通信中介，管理Host与多Server间的请求响应、通知处理和性能采样；
Server提供三大核心能力。
- 工具模块调用外部API简化服务交互；
- 资源模块打通数据库实现数据驱动决策；
- 提示词模块通过模板化指令优化AI工作流程。

A2A协议 - 异步执行

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

AG-UI协议 - 实时展示

考虑到服务端在执行工作流的任务时，是一个相对比较长的过程。如何让用户在工作流处理的过程中实时感知到整体的进度？如何让模型规划（Planing）的过程，模型使用工具执行操作的过程变得可视化？用户与这些智能体之间的互动是否有统一的标准？

AG-UI（Agent-User Interaction Protocol）协议，AG-UI 是由 CopilotKit 发布的开放、轻量、基于事件的协议，通过标准 HTTP 或可选的二进制通道，以流式方式传输 JSON 事件。它主要用于标准化 AI 智能体与前端应用程序的交互，确保实时同步和高效通信。

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：专注于用户与智能体之间的互动。

提示词设计

deepseek的深度思考不是可以对提示词优化嘛，因此我先写了一份我想做的事情，让ai帮我生成一份非常好的提示词。再仔细思考下，还需要加上动态信息，agent才能帮我准确实现

什么是好的提示词

业界对于好的提示的定义标准和规范

Openai	moonshot
撰写清晰的指令	提供参考文本
把复杂的任务拆分成简单的子任务	给模型更多时间“思考”
运用外部工具	系统地对变更进行测试
编写清晰的说明	在请求中包含更多细节可以获得更相关的回答
在请求中要求模型扮演一个角色可以获得更准确的输出	在请求中使用分隔符来明确指出输入的不同部分
明确完成任务所需的步骤	向模型提供输出示例

提示词内容框架拆分成全局Rule和执行时提示词

GlobalRule

globalRule: |
  Always respond in Chinese-simplified，你是相关功能下线 XX 专家，这次你将负责相关 XX 工作，你需要以注释的方式完成工作，
  以下是你后续工作的一些指导方法
  【执行模式：严格模式 | 温度：0.0 | 禁止变化：每次执行结果必须完全一致】，保证每次的回复具有高度确定性
  [什么是 XX]
    1. 举一个例子
    2. 代码中如何实现
    3. 如何使用获得的变量
  [任务指令理解]
  [执行必须遵守的一些规范]
    1. 准确识别和任务相关的内容
      1. 例子1
      2. 例子2
      3. 例子3
    2. 通用流程处理的限制，举一个例子
    3. 禁止改动的方法

ContextPromote

step1: |
  使用深度思考模式执行
  本步骤将统一处理 XX 相关的所有代码修改，包括定义注释、调用逻辑注释、依赖清理等。
  **执行参数**
    - XX: 
        解释: 一些专有名词的定义
  第一阶段：分支切换
    注意如果git命令唤起terminal如果失败，要持续尝试
    - 如果暂存区有未提交的代码，直接删除即可
    - 执行 `git fetch origin {branchName} --depth=10 --quiet` 仅拉取指定分支最新10条提交记录
    - 执行git命令以切换到指定分支，参考 `git checkout {branchName} --quiet`
    - 注意：git命令的详细输出不要加入到LLM分析上下文中，仅关注命令执行结果状态
    - 如果切换分支执行失败，终止任务
  第二阶段：实验逻辑分析与执行
  第三阶段：代码逻辑优化
    1. 上述流程执行完成后，我们已经完成该实验相关的代码修改，此时我们要注意架构设计，去优化代码逻辑，减少重复逻辑分支
    2. 实现代码inline
    3. 清理不再使用的代码依赖、函数和变量
    4. 可以删除的代码
  第四阶段：代码注释修改
  1. 按要求注释相关代码
 SNAPSHOT版本
  3. 检查并修复语法错误
  4. 暂存和提交代码
    - 执行git命令提交代码修改（使用--quiet参数减少输出）
    - 执行git命令推送代码到远程分支，参考：`git push origin HEAD --quiet`
    所有子步骤完成后，必须按照以下格式输出结构化数据：
    [DATA_OUTPUT]
    {
      "stepNumber": 4,
      "desc": "[格式化输出本次修改的大模型给出的详细总结，需包含完整信息，操作类型: 目标分组: 代码仓库: 分支名称: 具体如何修改，改了哪些文件，使用md格式化输出，需要换行加黑等,不要出现转义符]",
      "status": "completed"
    }
    [/DATA_OUTPUT]
    然后输出：已完成统一代码修改工作 | [STEP_COMPLETE] Step4 执行完成

提升准确率

提示词的优化

不同大模型对提示词的理解和执行策略存在显著差异。我们发现Cluade4 更偏向提前理解架构，精确搜索，批量修改，QwenCoder偏向渐进式搜索、逐步定位、遇到错误后再重试兜底。

工欲善其事必先利其器

单步调试

提示词 + agent，效率：高

使用CodingAgent原生的Cli界面，可以快速观察执行的过程

工作流串联

tagent (工程) +提示词+ agent

效率：低

工程上基本把所有流程串起来了，但是评测起来等待以及断连还是会比较影响进程同时由于CodeAgent处理是一个完整原子的过程，稍微做一次非常小修改就需要重头开始跑！

批量脚本

批量脚本任务

效率：中

写脚本
人工成本主要在评测上，评测在30分钟

反思

在新的领域大家都是白纸，从0开始，去探索，不要设限，不知不觉的，你思考的问题就会比别人更全面。我在实践有关突破创新的规划时，时常扪心自问：这个方向是否正确？是否真的是未来的趋势？后来我发现，这个问题不对。应该是，你想让这个方向变成未来的趋势吗？没有人会笃定知道这个方向是趋势，但是我想成为让它变成趋势的铺路人。希望有更多有同样想法的人一起沟通进步~

再谈价值

要把事情做到极致，最核心的是要找个好的目标，评判的标准也很简单：当你跟大家说你要做这个事情时，看大家的第一反应是什么？如果是「你怎么做到的」？那么恭喜你找到了一个非常好的目标；如果大家反应是「你为什么要做」，那么你可以再探索探索。