我要投稿

从 Copilot 到 Coding Agent，AI 驱动软件开发的未来

发布日期：2025-10-09 18:28:10 浏览次数： 1549

作者：DataFunSummit

微信搜一搜，关注“DataFunSummit”

导读在 AI 编程助手（Coding Agent）的快速发展中，有限上下文、知识沉淀、软件工程复杂性等问题成为制约其落地的核心挑战。当前，尽管行业巨头通过扩展上下文窗口、优化提示工程（如 Context Providing）和引入检索增强生成（RAG）等技术部分缓解了问题，但 AI 仍面临隐性知识缺失、反馈机制不足等拟人化能力短板。本次分享从企业实践视角出发，系统性剖析了 Coding Agent 的关键议题，为提升 AI 编程效率与质量提供了可落地的解决方案参考，同时揭示了未来 Agent 发展的核心方向：从“工具”进化为具备持续学习与协作能力的“拟人员工”。

今天的介绍会围绕下面六点展开：

1. 有限上下文

2. 知识如何积淀

3. 软件工程的复杂性

4. 反馈循环

5. 24 小时不停歇的 Agent

6. 总结

分享嘉宾｜王振威 Gbox AI CTO

编辑整理｜马朝威

内容校对｜郭慧敏

出品社区｜DataFun

很高兴今天与大家共同探讨 Coding Agent 当前面临的两个核心挑战：知识沉淀困境与盲写问题（虽然无法提供最终解决方案）。

基于我们团队内部实践，我将从企业级应用视角，分享这两个问题的当前行业现状如何？造成这种现状的原因是什么？目前领域的研究进展到了什么阶段？以及使用时的关键注意事项，希望能够为大家的实际应用提供有价值的实践参考。

有限上下文

1. 模型的硬限制

关于有限上下文问题，虽然大家都知道存在 8K、16K 甚至 1M 的限制，但关键问题在于模型的硬性限制机制。

需要明确的是：模型的上下文长度是指输入和输出内容的总和。很多人存在误解，认为只要控制输入内容的长度就可以了，这种理解是不准确的。不过在实际使用时，这个细节问题往往不会引起太多注意。

2. 注意力不够

核心问题在于：2022 至 2023 年间，当上下文长度限制凸显后，各大厂商纷纷扩展上下文容量，目前已达 10M token（约 1000 万 token，相当于一本巨著）。但大模型表现不佳（难以完成复杂任务或产出高质量内容）的根本原因存在认知偏差：

人脑对比：高水平程序员也无法同时处理如此海量的信息
实际表现：即使输入完整开源项目代码库及提交历史，模型仍难以胜任复杂任务
本质原因：性能瓶颈不在上下文容量，而在注意力机制限制

这与人类认知高度相似：如同新员工听完所有业务培训也无法立即高效工作，因其无法同时处理过量信息。大模型同样受困于信息过载，这一认知正推动技术方案的迭代演进。

3. Context Providing

我们需要考虑如何在大模型的上下文中提供足够且有效的信息。

信息不足：信息不足就无法解决问题，模型自然无法正确处理。
无效信息：如果输入的都是无效信息，模型也会困惑，无法抓住重点。

当前，"Context Providing"正成为行业新焦点。相比传统的提示词工程（Prompt Engineering），如今模型所需的上下文已扩展至背景信息、需求说明等多维内容——这正是"Context Providing"概念兴起的原因。

对使用 Coding Agent 的企业而言，优化上下文质量应是提升产出的首要切入点。

4. What in Developer/Agent head？

对比人类与 AI 的差异：

人类：程序员大脑中储存着大量隐性上下文——从入职第一天起积累的公司代码、文档知识、老板偏好、产品需求和设计规范等。
AI：AI 就像一个刚毕业的大学生，对公司一无所知，仅能依靠有限的 16K 上下文内容工作。

人类与 AI 的差异决定了 AI 难以做到完美。比如，人类能敏锐捕捉老板没有说出口的真实需求——是追求速度还是质量？这些无法量化的隐性信息正是 AI 的短板，也是人类程序员的优势所在。若有一天 AI 真能掌握这些，程序员恐怕真要失业了。

因此，AI 常像第一天入职的新人——面对老板扔来的厚厚资料，只剩茫然。

5. Context Engineering

如何让 AI 表现更出色？关键在于优化上下文组织——这正是"上下文工程"的核心。

LangChain 团队的研究表明：有效的 AI 输入需要系统化的上下文记录、存储和整合流程。虽然行业正在通过 MCP 工具等方案推进这一方向，但我们认为 AI 的终极形态应是拟人化的——具备类人的认知和工作方式。

6. 最佳 Context Providing 入口：IDE（目前）

当前，IDE 已成为 Context Providing 的最高效载体。与 ChatGPT 依赖手动粘贴的低效方式不同，IDE（如 Cursor、KIRO）通过 MCP 直接访问代码仓库，并支持命令行信息无缝导入，大幅提升了信息组织效率。

这种模式下，人类角色转变为 AI 的上下文组织者。组织上下文的效率，已成为决定 AI 产出质量的关键因素。这也解释了为何网页版 Coding Agent 几乎全军覆没，而 IDE 集成的 Cursor 却最成功。值得注意的是，即便是命令行工具 Claude Code，其主要使用场景仍是 IDE 集成，核心价值就在于本地仓库的高效访问能力。

行业格局清晰印证了这一趋势：从 Cursor、Windsurf 到亚马逊 KIRO、字节 TRAE，各大科技公司都在积极布局 IDE 赛道。这揭示了一个明确共识：当前阶段的技术竞争，本质上就是 Context Providing 效率的比拼。对开发者而言同样如此——要获得更优质的 AI 生成代码，关键在于建立高效的上下文组织并提供充分信息。

知识如何积淀

接下来我们需要探讨的关键问题是：

AI 如何像真正人类一样工作，而不是像一个新员工那样，每天抱着一本厚厚的操作手册开始工作。这个问题的解决之道，实际上堪称全球范围内的顶级难题。

1. RAG&Graph based RAG

当前业界普遍采用 RAG 技术（包括基础版和图数据库升级版）来解决上下文信息不足的问题。这类方案通过外挂知识库，按需提取相关信息片段进行辅助处理，但与人类认知方式存在本质区别。

以开发计费系统为例：在 16K 上下文窗口限制下，AI 只能获取"计费"相关的文档片段。相比之下，资深工程师能基于完整的系统认知、丰富的项目经验和产品理解，形成立体化的知识体系。

这种认知差距使得 RAG 目前最适用于客服等检索型场景，而对需要深度信息处理的任务仍有明显局限。尽管如此，在现有技术条件下，RAG 仍是最可行的实践方案。

2. Fine Tuning

第二种方法是微调（Fine-Tuning），即用特定场景数据对预训练模型进行额外训练。但当前 FT 方案存在明显局限：

权限限制：全球顶尖大模型（如 OpenAI）通常不开放微调权限。
技术门槛：微调成熟度不足，缺乏即用型方案，中小企业难以落地。
迭代风险：微调成果可能会因为基础模型的更新而变得毫无价值。

这使得中小企业陷入是否投入的决策困境。虽然 FT 仍是当前可用的知识沉淀手段，但并非终极方案——理想的方案必然是拟人化的，就像人类能够实时理解完整上下文的能力。

3. 人是实时整合上下文的，LLM 不是

以 Claude Code 为例（上图是其界面截图），这款工具最近很受欢迎。但在实际使用中，比如用 Postman 调用接口返回 500 错误时，人类能快速从冗长日志中提取关键错误信息并整合到当前任务中，而 AI 即使接收完整日志（MCP 格式或直接拖拽）也难以做到。

这体现了人类与 AI 的核心差异：AI 虽具备长上下文处理能力，但缺乏智能筛选关键信息的能力。Claude Code 为此提供了 Compact 命令来摘要长文本，但摘要过程难免丢失重要信息。

预训练模型就像刚毕业的博士生：聪明但缺乏沉淀。它不会像人类员工那样随着经验积累成长为资深专家，因为它的"大脑"无法持续学习。要将企业私有知识内化到模型中，必须通过训练实现，而目前的微调方案仍不完善。

4. Train/Inference

传统上，模型的使用分为训练和推理两个阶段。训练阶段使用的是预训练模型，比如 DeepSeek、豆包等大厂提供的模型。

当前 AI 模型的训练机制是：通过数据输入和结果预测，根据正/负反馈动态调整模型权重（参数）。然而，一旦预训练完成并部署，这些权重便固化，仅用于推理计算，不再更新。

当前 AI 领域的通用模式类似于博士生培养：预训练是学习阶段，推理是工作阶段。但区别在于，人类会持续积累知识，而 AI 的记忆是固化的——它无法在实际应用中自我提升。虽然可以通过 RAG 技术（检索增强生成）给 AI 挂载"企业参考手册"，但这只是外部辅助，AI 的核心能力并未增强。

因此，Online Learning 才是终极解决方案。但目前全球顶尖厂商在该领域的进展仍然缓慢。

5. 我们想要 Online Learning

Online Learning 是指在模型推理过程中同步进行训练和反馈。预训练阶段仍然必不可少，但在实际应用时，当外部需求或新知识输入后，系统会通过特定机制（如上图中红线所示）实时修改大模型的权重。这样，新知识就能被真正内化到模型中。

目前这一形式在工程实践上尚未完全走通。尽管全球顶级大厂内部已有 Demo 验证可行性，但离工程化落地仍有距离。行业正朝"训推一体"方向演进，部分企业已在尝试 Online Learning，但实时权重更新仍未实现。

6. 顶级大厂在 Online Learning 的态度

我们来看看三家顶级大厂在 Online Learning 的态度：

OpenAI 公司的方案

OpenAI 此前推出了 ChatGPT Memory 功能，目的是让 ChatGPT 能够记住用户偏好。但据我们了解，这一功能并非通过修改模型权重实现，很可能是采用了更高级的 LoRA 处理方式，类似于 Finetune 或 RAG 技术，仍然属于外置方案。它并未真正修改预训练模型，因为这类模型（如 OpenAI 内部的 O3 级别模型）据外界猜测具有万亿级参数规模。若为单个用户修改参数，其他用户将无法使用，其体量和成本都极其巨大。因此从效果和各方面判断，外界猜测 OpenAI 尚未实现对大模型参数的实时修改，仍在使用更高水平的 Memory 方案。

DeepMind 公司的方案

DeepMind 公司使用了"反思 Agent"方案，这一方案值得企业尝试。其核心逻辑是：不依赖外部记忆（类似 RAG 等技术），而是让 Agent 在产出结果后，以另一种身份对内容进行审视，从而从外部获取不同信息。但这仍属于工程方法层面的解决方案。

Anthropic（Claude 的开发公司）的方案

Anthropic目前未见其布局 Online Learning，但他们非常重视 Context Providing 和推理过程中的反馈机制。虽然其模型无法真正记住用户信息，但特别注重在推理阶段快速响应用户反馈。他们提出的"宪法 AI"框架，通过预设原则（如代码风格规范等）使同一预训练模型（如 Claude 3.7 Sonnet）能适配不同企业的特定需求。例如，不同企业可以制定各自的"宪法"：A 公司可要求所有代码采用特定风格，B 公司则可选择另一种风格。不过严格来说，这不能算 Online Learning，但对解决企业特异性问题确有帮助。

7. 有了 Online Learning 和好的 Context 后，还需要什么？

虽然目前还没有真正的 Online Learning，但如果这个"博士生"（预训练好的 AI）不仅智力超群、知识广博，还能在日常工作中逐步了解你公司的知识库，那么在这种情况下，当我们为其组织好工作上下文后，使用体验将完全不同。这时的工作会变得非常轻松。

如果具备 Online Learning 能力，AI 就能与企业形成默契。它会了解企业的工作习惯，甚至知道去哪里查询信息来确定字段类型。这时你只需像老板交代任务一样简单说一句"帮我搞定这个事情"，而不需要列出所有细节，因为它已经内化了这些知识。

举个有趣的例子：

同事在群里问"有没有推荐的机场？"在程序员语境中，"机场"特指科学上网工具。但普通 AI（如 Cursor 或 OpenAI）会按字面理解，推荐真实机场——因为它不了解你们的隐性语境。这正是当前 AI 的局限：缺乏对私有信息和特定环境的深度理解。而如果 AI 能持续学习并组织好上下文，它就能正确完成任务。

还有一个关键问题：如何确保 AI 的工作成果是正确的？

我们前面讨论的所有方案——组织上下文、调用外部记忆，甚至是实现大模型权重级别的实时微调——都只能从理论上提高 AI 的表现。但实际效果仍需要反馈机制来验证和完善。例如当你招聘一个博士生加入团队时，即便他能力出众，你仍然需要验证他的工作成果。

软件工程的复杂性

1. AI 革新了编码，但没有革新软件工程

软件工程经过几十年的发展，已经形成完整的工程流程：从产品需求调研、设计、开发，到测试、上线和运维部署。这套完整的流程中，每个环节都可以引入 AI 技术。

但目前 AI 对整个软件开发链条的冲击是局部的、碎片化的，而非系统性变革。即便在单个环节的应用，也仍然需要人工参与和监督。这就是当前典型的软件迭代过程中 AI 的应用现状。

2. 高质量的产出的前置条件：Spec，Context，Constitution，Feedback

如果我们要像对待新员工一样对待 Coding Agent，还需要为其提供以下几个关键要素：

Spec：输入输出、功能目标、性能指标，以及各种兼容性需求等。

就像博士生入职需要了解公司规章制度一样，我们需要明确告知 AI 任务的具体要求。即便 AI 已经掌握公司私有知识，如果这些要求表述不清，其表现也会大打折扣。因此，即便实现了 Online Learning，明确提要求仍然必不可少。这或许正是 AI 时代人类的新角色——AI 的需求规划师。

Context：环境说明，项目背景与结构，会话与上下文记忆。

针对具体任务，需要提供足够的工具环境及相关信息。

Constitution：可维护性约束，安全与合规规则，行为解释与拒绝能力。

就像宪法 AI 所倡导的，我们需要建立规范体系来保障代码质量。

Feedback（最重要的环节）：测试、静态分析、观测信息、人工反馈、自检环境、授权与工具。

某种程度上，人类将扮演质检角色：我们既可以直接测试 AI 输出，也可以要求 AI 自测——比如配置静态分析工具来检查代码复杂度等。为 AI 提供完整的观测信息：日志记录、性能指标等，否则它无法自主优化。此外，人工反馈（如对代码结构的意见）也不可或缺。

质检环境同样关键。就像为新入职的博士生配备高性能电脑，我们也需要为 AI 搭建完整的测试环境。只有配备适当工具，AI 才能从我们的视角全面测试代码。否则就是"盲写"——这正是我们要解决的第二个核心问题。所有授权工具的设计都要避免盲写情况。

我们要规范 AI 的产出流程：通过精准需求引导，让 AI 生成代码并自主完成测试，直接交付可用成果，而非半成品。

3. Spec 书写能力决定了未来程序员的价值

Coding Agent 正在全球范围内改变程序员的工作方式。未来，编写清晰、逻辑严谨的 Spec 将成为程序员的核心技能——只有这样才能让 AI 发挥最大效能。关键在于两点：需求明确，逻辑清晰。

4. Context 组织能力决定了 Vibe Coding 的效率

组织上下文的质量直接决定了工作效率。当你提供完整的信息时，Coding Agent 的工作流程就不会轻易中断，你可以轻松地监督它的工作，甚至边喝咖啡边观察。反之，如果信息不足，Agent 就会频繁遇到问题，比如不断询问"这个该怎么办"或"我缺乏必要信息"——这本质上都是因为上下文组织不充分。就目前而言，在 IDE 中组织上下文远比复制粘贴高效。

因此，在为任何 Agent 组织上下文时，核心考量应该是：哪种形式能让你获得最高的工作效率？这个原则同样适用于其他领域的 Agent 应用。

当 Agent 表现不佳时，首先要检查信息是否给足：

如果信息充足但表现不理想，那就是 Agent 自身的能力问题；
如果信息本身不足，那就是我们使用者的问题。作为使用者，我们必须学会高效地提供足够丰富、准确的信息。

5. Constitution 归纳能力决定交付质量和团队效率

Constitution 规范将直接决定团队的工作效率和交付质量。尤其在团队扩张时，缺乏统一标准必然会导致整体效率下降，问题频出——就像拆东墙补西墙疲于应付。而明确的规范能有效预防这些问题。

例如：团队能否统一使用某种通信协议？能否采用一致的数据库操作方式？能否遵循统一的代码风格？能否使用标准化的内外测试工具？

若让 AI 掌握这些规范，它就能像熟练员工一样工作，既提升效率又保证质量，最终成为团队的高效成员。

6. Feedback 决定了交付的业务价值，是最重要的环节

归根结底，最重要的始终是 Feedback。无论写代码还是其他工作，最终都要交付业务价值。业务价值的评判标准不是 Context Providing 的质量，不是代码生成速度，也不是 AI 的智力水平，而是老板是否满意、客户是否愿意付费、用户是否认可。因此，这些业务价值最终只能通过 Feedback 来验证，尤其是来自业务侧的 Feedback。

举例来说：当老板要求开发一个小程序或网页时，即便 AI 快速完成了代码，如果没有经过人工测试和最终验证，写得再好也毫无意义。这个关键环节往往被很多人忽视。实际上，就像我们程序员交付前会自测一样——你会让测试团队介入，会让产品经理验收，但首先你自己一定会做自测。不过说实话，人类也不喜欢自测，我们更希望 AI 能够自主完成这个环节。

7. Coding Agent 更需要工程

Coding Agent同样如此，和人类开发者一样，它也需要通过完整的软件工程流程来确保交付质量、规范工作流程和保障效率。如果没有经过充分测试，我们同样不敢贸然交付。

反馈循环

那么如何进行测试呢？

测试无疑是整个反馈循环中最重要的环节。这个反馈循环不仅包含测试，还包括日志信息、性能指标（metrics）等多个关键组成部分。

1. Coding Agent 乱写？

关于代码质量的问题，如果我们能提供有效反馈，情况就会改善很多。这就像去医院看病一样，当前 AI 面临的困境是：我们往往只提供片段式反馈，比如在聊天窗口简单指出"这里写错了，重写"，或者粘贴部分错误日志，却缺乏完整的诊断信息。这种不完整的反馈对 AI 解决问题帮助有限。

就像医生需要综合检验报告、症状描述等多方面信息才能准确诊断一样，程序员解决 bug 时也会综合各种信息在大脑中还原问题场景。例如接口报 500 错误时，我们会查看后端日志的调用栈，定位空指针等具体问题。同样，如果 AI 能获得这些综合信息，特别是面对复杂问题时，它的解决能力将大幅提升。

目前 Coding Agent 已能处理简单问题（如根据错误日志修复后端接口报错），但用户不满的核心在于复杂场景：仅凭日志无法解决的问题，或是性能优化等需要全局视角的任务。这时就需要反思：我们是否提供了足够全面的信息？是否配备了充分的验证和测试工具？

2. Coding Agent 必须具备自测能力

既然 AI 能够自主编写代码，为什么不能自主测试呢？

这与人类程序员的工作流程类似：优化性能时，我们会先测量当前指标（如接口耗时 500ms），设定目标（如 100ms），修改代码后重新测试。若耗时降至 380ms 仍未达标，就进一步分析链路追踪数据，定位瓶颈。

但在 AI 协作中，我们却期望它不借助任何工具就能直接从 500ms 优化到 100ms——这无异于“脑运”。如果为AI配备相应的测试工具，它同样可以像人类一样逐步优化。

3. 拒绝盲写，从 Agent 自测开始

若能建立起这样的循环机制（特指让 AI 自主建立的反馈优化循环），相信它完全有能力高质量地交付各类复杂任务。

4. Agents 的环境和权限

在此之前，我们必须为 AI 配备完整的开发环境，不能再单纯依赖它的"脑力运算"。即便使用全球最顶尖的模型，仅靠"脑运"来解决复杂问题也是不够的。它需要一个真实的开发环境，最好是与你们团队完全一致的工作环境。

上面图中是在 Cursor 的 Agent 模式，使用的是全球顶尖的 O3 模型。让它尝试编写一个非常简单的安卓应用，但仅靠"脑力运算"就出错了。实际上这是一个很基础的任务：实现登录功能，没有程序员会写不出来。O3 确实写出来了，但登录会失败，原因只是安卓框架中一个网络权限属性没开启。模型自信地完成了任务，按钮布局和调用链路都没问题，却因为缺乏测试环境而遗漏了这个简单问题。

我们公司开发的 gbox 正是为了解决这个问题：为各类 Coding Agent 提供包括 Linux、浏览器和安卓等在内的完整环境，让 AI 能安全验证工作成果。即 O3 在我们的环境中点击按钮时，安卓系统弹出 Toast 报错提示，它立即意识到缺失权限并修正代码，最终交付可运行的版本。

我认为 O3 的智力已远超人类程序员，只要配备和人类相同的工具、信息和权限，很多工作确实不需要人类参与了。但目前存在两个关键差距：

模型缺乏人类实时整合上下文的能力（人类会过滤无用信息）；
模型处于"高智商大脑却无手脚"的状态，缺乏执行环境。

gbox 就是要补全这个闭环。近期很火的中国公司 Manus 也是类似思路（虽然面向更通用的智能体），都强调为 AI 提供可操作的计算环境。

5. Claude Code hooks 提供检查的反馈

测试反馈是最关键的环节，因为它直接反映业务侧是否满意。

虽然单元测试、接口测试和压力测试都重要，但最重要的是用户视角的端到端测试。只要通过端到端测试，就说明软件交付后用户基本会满意，这样的 AI 交付成果才更容易被大家接受。

测试并非唯一的反馈方式。Claude Code 近期新增的 hooks 功能，本质上也是为模型提供反馈机制。它允许模型在使用外部工具或编写代码时执行外部命令并获取结果。例如我们团队配置的 team run check 就包含这些内容：Lint 检查（几乎所有团队都会用）、ES 规范要求，以及我们内部特有的规范（如代码行数限制、注释格式等）。