现在挑 Coding Agent，难点已经不是找一个“能改代码”的工具。Claude Code、Cursor、Copilot、OpenCode、Qwen Code 的 Agent 入口都能处理仓库中的开发任务，功能表看起来很像。等到要把工具放进自己的开发流程，问题才具体起来：开发者要不要一直盯着 Diff？代码能不能离开本地？任务中断后怎么接着做？
这些问题很难从模型排行榜里找到答案。IDE Agent 把修改放在眼前，适合边做边审；终端 Agent 能沿着测试反馈持续排查；云端产品把任务交出去，回来验收 PR。若想自行改工具接入、权限或执行循环，还得看 Harness 开放到哪一层。同样叫 Coding Agent，开发者介入的位置和要承担的责任并不一样。
最近我把国内外有代表性的产品文档和开源仓库放在一起，按实际工作入口与执行层开放程度重新梳理。这份整理想帮大家先缩小适合自己任务的候选，再问清代码在哪运行、Agent 能做什么、结果由什么来验收。
01 模型、Agent、Harness、平台不是一回事
选型讨论容易打转，一个原因是“模型”“Agent”“Harness”“平台”经常被混用。模型负责理解任务、提出判断并生成代码；Coding Agent 在仓库中搜索、调用工具、修改文件，再读取执行结果；Agent Harness 组织这轮循环里的工具、权限、上下文、会话状态和异常恢复。IDE 或云端平台则把它们接入开发者的工作环境，可能同时承担 Git、部署、审查和团队协作。
开发任务与已有仓库
│
▼
任务与约束（范围、权限、验收标准）
│
▼
Coding Agent（用户接触的执行主体）
│
├── 模型：分析错误、决定下一步
├── Harness：上下文、工具、权限、执行循环
└── 运行环境：本地终端 / IDE / 沙箱 / 云端工作区
│
▼
代码变更 + 构建测试 + 证据 + 人工验收
注意：开源模型与开源 Harness 是两回事。Qwen 或 DeepSeek 可以是某个 Agent 使用的模型，但不能据此认定这个 Agent 的执行框架开源。同样，某个 Coding Agent 采用 MIT 或 Apache-2.0 许可证，并不意味着它调用的模型 API 免费，更不意味着数据一定只留在本地。
“开源”还得问开放的是哪一层。Codex CLI 仓库采用 Apache-2.0，相关托管服务却有独立的产品条款；一个使用开放权重模型的 IDE，也可能不开放自身运行时。下文按所讨论的产品入口及其主要执行层分组。商业产品可以提供 API 和扩展，开源项目调用的模型与云服务也可能收费或闭源。
| 手里的任务 |
先比较的入口 |
第一轮看什么 |
| 维护现有仓库，开发者随时审查 |
IDE Agent、终端 Agent |
定位是否准确、Diff 是否克制、测试能否复现 |
| 边界清楚的长任务，回来验收结果 |
云端委派、PR 工作流 |
隔离环境、停止条件、失败回报、审查记录 |
| 从零做可运行小工具 |
应用工作台、AI IDE、通用任务工作台 |
本地可重建、依赖和部署是否可迁移 |
| 自己改工具链或研究 Harness |
开源 CLI、运行时、研究框架 |
扩展面、权限边界、会话与工具轨迹 |
| 内部仓库有严格数据要求 |
符合组织要求的企业方案或自部署入口 |
实际数据流、身份权限、审计和模型位置 |
下面就跟云朵君一起来看看都有哪些工具，然后根据需求来选择适合自己的工具。
02 海外商业 Coding Agent：把执行能力做成完整产品
这些工具不需要开发者从零搭建 Harness，但它们强调的工作入口并不一样。我先从上手频率最高的终端、IDE 工具说起，再看云端任务委派和企业平台。
1. Claude Code：在终端里把修复任务跑成一条闭环
Claude Code 官方文档｜主要形态：终端 Coding Agent，支持与编辑器、开发工具链集成
如果把“查 PDF 导出调用链、修改、运行测试、重新修复”写成一个任务，Claude Code 的优势在于这些步骤可以在同一个会话里连续发生。它并不只是回答代码问题，而是通过文件操作、Shell 命令、项目上下文和工具反馈推进工作。开发者可以用 CLAUDE.md 明确项目规则，用 Skills 固定重复流程，用 Hooks 在关键节点引入外部检查；相对复杂的任务可以委派给子 Agent，让主会话保留总体判断。
我会在项目里先写清两条约束：不能删除已有导出格式；修改必须附带缺页回归测试。然后让它先梳理分页计算、页面写入以及最终保存三个阶段的调用关系。到了修复环节，测试失败的日志重新进入执行循环，而不是让我复制粘贴下一轮提示词。
不过“能连续执行”不代表“任何操作都应该自动批准”。权限模式、Shell 命令、外部仓库和插件的访问边界仍然要单独设置。对于重要代码，我更关心它能否给出完整 Diff、测试输出和未解决问题，而不是一句“已修复”。Claude Code 适合终端工作流比较成熟、愿意以任务驱动开发的个人和团队。
2. Cursor：把 Agent 的操作放在代码编辑现场
Cursor 官网｜主要形态：AI 原生 IDE，兼有 Agent 与终端等入口
同样的故障，Cursor 的切入点更贴近编辑器。定位错误时，可以边看项目目录、相关符号和代码差异，边让 Agent 搜索、修改多个文件、执行命令。其吸引力并不只是能调用模型，而是把代码理解、编辑器导航、变更审查与 Agent 操作放在一处，降低开发者在终端、聊天框和文件树之间来回切换的成本。
例如修复前先打开 export 模块，看分页状态是否被两个异步任务共用；修改后直接逐段审查条件分支。对需要频繁介入的重构任务，这种“边改边看”的节奏很好用。如果团队习惯使用特定编辑器插件或高度定制的开发环境，迁入 Cursor 的编辑器体系也会有适配成本。
它与 Claude Code 不是简单的“谁更聪明”：一个优先优化 IDE 内的人机协作，另一个优先优化在终端中组织执行过程。模型能力、任务描述和权限配置相同之前，直接比较一次演示效果没有太大意义。
3. GitHub Copilot：把 Agent 放进已有的 PR 和协作链路
GitHub Copilot｜主要形态：编辑器助手、Agent 模式与 GitHub 工作流
Copilot 最早让很多人习惯了补全，现在更值得看的是它怎样与仓库、Issue、Pull Request 和自动化检查连接。对一个已经用 GitHub 协作的团队来说，“让 AI 修改代码”只是前半段；真正耗时间的往往是提交变更、触发 CI、回应 Review，以及确认能否合并。
在 PDF 缺页场景里，我可以把复现步骤和验收要求写进 Issue，让 Agent 在授权范围内处理代码变更，然后通过 PR 来审查结果。它的优势是接入既有协作基础设施，而不是要求每个开发者学一套全新的任务管理方式。
但必须区分编辑器里实时协助的 Copilot、仓库托管的 Coding Agent 和组织策略。不同入口的操作权限、可用模型和部署方式不完全相同。需要团队审查与合规记录时，它比单纯追求“一键生成页面”的产品更值得比较。
4. Devin：让一个边界明确的开发任务独立推进
Devin 官网｜主要形态：云端、偏长任务的软件工程 Agent
Devin 主打的不是开发者打一行它补一行，而是把“分析仓库—修改—验证—提交 PR”当作可以委派的工作。比如现有系统里有 30 个历史接口需要统一调整类型定义，我可以把任务范围、兼容要求和测试命令交给它，在隔离工作环境里处理，随后集中审查产物。
放到 PDF 故障上，Devin 更适合这样的任务单：给定可复现样例、相关仓库、CI 流程，要求提交最小修复 PR。它的任务体验比较接近把工作交给远程同事，意味着前期说明和后期验收都要明确。
这类云端委派产品必须特别核对代码、依赖和运行日志的流向。任务若高度依赖本地硬件、受限内部网络或只能人工判断的交互细节，远程自主执行不一定合适。少盯执行过程，不等于可以少做最终验收。
5. Windsurf：让编辑器持续跟随当前开发意图
Windsurf 官网｜主要形态：AI 编程 IDE，核心交互包括 Cascade
Windsurf 的关注点是开发者在工程里不断移动时，Agent 能否跟上“我正在做什么”。它把多文件编辑、对话、命令执行和编辑器环境整合进连续的开发流中。对于一边浏览导出模块、一边发现新错误的场景，这种交互比反复重新描述当前文件和任务要自然。
比如我先让它解释 PDF 页面切分逻辑，随后指向某个渲染入口问“这里为什么会复用上一次导出的缓存”，再要求只调整这一条链路。它更适合边探索边收敛方案的开发，而不是默认将一个复杂需求完全交给后台无人值守执行。
与 Cursor 一样，评估 Windsurf 时需要把注意力放在代码导航、变更审查和上下文延续上，而不是把编辑器 UI 的流畅等同于问题修复质量。团队原有插件、远程环境和代码审查方式，也会影响迁移成本。
6. Google Antigravity：从单次编码转向 Agent 工作空间
Google Antigravity｜主要形态：Agent 开发环境与终端工作流
Google 的方向是把更复杂的任务执行、工具环境与多个工作单元放在统一的开发体验中。遇到“前端导出页显示成功、实际文件却缺页”这种跨 UI、后台生成和测试的故障，真正有用的不是多弹出一个聊天框，而是将调查、代码修复和验证步骤分开，保留清晰的执行痕迹。
需要把它和 Gemini CLI 的开源仓库分开看。Google 在 2026 年将个人账号的终端体验转向 Antigravity CLI；Gemini CLI 仓库仍以 Apache-2.0 开源，企业许可和付费 API Key 的访问继续得到支持。官方迁移说明。因此不能拿旧版 Gemini CLI 的个人账号体验推断现在的 Antigravity，也不能说开源项目已经消失。
评估时我会核对实际执行沙箱、插件接口、计划任务的持续性和企业账号权限，而不是把桌面端、CLI 与旧产品的功能混为一谈。
7. Factory（Droid）：让团队用统一规则部署专门的 Agent
Factory 官网｜主要形态：面向团队的软件工程 Agent 平台
个人开发时，一个通用 Agent 常常够用。团队若同时做代码审查、版本迁移和故障处理，就需要给不同任务配置指令、工具和工作流。Factory 将这些配置组织成 Droid，供团队在工程活动中调用。
比如我会把“PDF 导出缺页修复”拆成两条团队流程：一条负责定位和修改，另一条只检查回归测试、变更范围和兼容性。强调的是同一类任务由相同的执行规则处理，降低每个人临时写提示词导致的差异。
它的代价是组织层面的建设：要梳理仓库授权、身份、日志、模板维护和质量门禁。对于只有一两个开发者的小项目，先用成熟的通用 Coding Agent 往往更直接。
8. Amazon Q Developer：AWS 工程问题更接近它的主场
Amazon Q Developer｜主要形态：AWS 开发生态中的编程与云工程助手
把工具放回具体业务才能看出差异。假设 PDF 导出服务运行在 Lambda 上，缺页与超时、内存峰值或 S3 上传过程相关，这时需要同时看应用代码、云配置和执行日志。Amazon Q Developer 的价值正是更贴近 AWS 的开发和基础设施工作流，而不是单纯替代任意一个通用代码编辑器。
我会用它检查应用侧修复是否需要配合 IAM、Lambda 或部署配置调整，再把真正改动落到可审查的基础设施代码上。这里不能把“能够解释 AWS 服务”误认为“自动获得当前 AWS 账号的访问权限”，权限仍受身份和配置控制。
如果项目根本不依赖 AWS，而是纯本地 Python 或前端开发，它的生态集成优势就不那么明显；此时应优先比较更通用的 Agent。
9. Replit Agent：从一句需求到可运行原型的闭环
Replit Agent｜主要形态：浏览器云端 IDE 与应用生成、运行、部署
如果手里还没有仓库，只是想做一个“上传图片—生成 PDF—在线预览”的小工具，Replit Agent 这样的产品比较容易体现价值：从需求出发搭建文件、安装依赖、运行应用并给出可查看的页面。工具执行与预览都发生在同一个云端环境，初次使用的门槛比较低。
不过这也是它与企业存量项目的分界线。原型能在托管工作区跑起来，不等于代码已经满足长期维护、迁移部署和安全要求。 等到业务变复杂，仍要检查项目结构、版本控制、第三方依赖、导出产物和部署成本。
10. Muse Code：多 Agent 终端产品，先看真实可用范围
Muse Code 官方入口｜主要形态：Meta 的多 Agent 终端编码产品
Meta 将 Muse Code 定位为终端中的多 Agent 编码产品，公开材料展示了子 Agent 在隔离工作区并行处理任务的方式。它代表了一种明确的产品选择：将任务拆成多个工作单元，而不只让一个 Agent 顺序调用工具。具体能力与可用区域、套餐和版本仍需按官方当前说明核对。
评估 Muse Code 时应核对支持的平台、执行权限、工作区隔离与失败恢复，再与同属终端入口的候选在相同任务上比较。并行工作单元能否正确集成，仍要看最后的 Diff 与测试结果。
03 海外开源项目：不仅能用，还能研究执行过程
开源项目最大的额外价值，是有机会检查 Harness 的实现与二次开发接口。不过开放代码不能代替产品质量，也不能自动解决沙箱和密钥问题。我会把它们分成三类来看：日常开发成品、偏可定制的执行内核，以及与编程相关但不是纯 Coding Agent 的系统。
1. OpenCode：在开放框架上做相对完整的开发体验
OpenCode｜MIT｜主要形态：开源 Coding Agent，提供终端等多种入口
OpenCode 与 Pi 的差别很有代表性：它更愿意把可用的 Coding Agent 产品直接交到开发者手里，包括多模型接入、文件操作、会话和工作区体验。对 PDF 缺页问题，我可以像使用成熟商用 Agent 一样，让它搜索仓库、修改文件、跑测试，并且能审查底层实现或按需要改接入方式。
我尤其会拿它来做模型与 Harness 分离的对照实验：固定同一个仓库、同一个任务和同一套工具配置，再调整模型服务。这样观察到的差异更容易归因，而不是同时换 IDE、执行器和提示词。
但“多模型支持”不等于每家模型都能在工具调用、长上下文和价格上无缝等价。升级后还要注意配置和插件兼容。对于想用开源 Coding Agent 直接开展日常开发的人，OpenCode 是非常自然的候选。
2. Pi：故意把 Harness 保持得很小
Pi｜主要形态：极简终端 Agent Harness，支持 SDK、RPC、扩展与树形会话
如果说 OpenCode 优先解决“我今天就要用它改代码”，Pi 还会追问：“这个执行系统哪些部分应该由我自己决定？”它用较小的核心提供工具调用、会话管理、上下文、交互和扩展入口。开发者可以用 TypeScript Extensions 定义特殊工具、拦截执行事件或调整上下文策略，通过 SDK 或 RPC 把 Agent 嵌进别的应用。
在 PDF 场景下，我可能不满足于普通的 npm test，而是需要一个专用工具：生成两份 PDF、读取页数和页面哈希、对比差异，只有满足规则才允许结束。Pi 适合把这种项目特定的验证器真正接进执行闭环，而不只是每次提醒模型“记得检查”。
代价是更多工程责任归开发者。某些多 Agent、规划与权限确认方式需要额外配置或扩展，不应假设开箱即用。它适合研究 Harness、开发定制工具或嵌入式 Agent，而不一定是最省配置的选择。
3. Codex CLI：开源终端 Agent，不要与商业服务混为一谈
Codex CLI 核心仓库｜Apache-2.0｜主要形态：本地终端 Coding Agent；另有产品化服务与界面
Codex CLI 放在开源一组，是因为它的核心代码仓库公开并采用 Apache-2.0 许可证。它的价值不只在模型本身，而是能在代码仓库里阅读文件、修改代码、运行命令，并把执行行为放进具体的权限与沙箱策略中。
例如我会在一个单独的 Git worktree 里让它定位 PDF 导出错误，先禁止修改仓库外文件，再要求提供最小补丁。这样模型选择、运行权限、Git 隔离和最终代码审查才有明确的边界。
需要分开评估两件事：本地 CLI 的开源程度和实际使用何种云模型、账号额度、托管服务。前者可以查看或修改核心实现，后者仍受服务条款和产品限制约束。不能因为 CLI 开源就默认所有执行和数据处理都在本地完成。
4. Gemini CLI：开源仓库仍在，个人账号入口已经改变
Gemini CLI 官方仓库｜Apache-2.0｜主要形态：开源终端 Coding Agent
Gemini CLI 的执行代码仍公开，适合研究终端 Agent 的工具、会话与扩展实现，也可在官方支持的企业许可或付费 API Key 场景下使用。它与 Antigravity CLI 应分开评估：2026 年的迁移改变了个人账号的终端入口，却没有撤销 Gemini CLI 的开源仓库。官方迁移说明
如果团队已有 Gemini CLI 的脚本或扩展，先确认当前认证方式、可用模型与维护范围；如果是个人用户新选终端产品，则应把 Antigravity CLI 当作另一项产品比较，而不是照旧教程直接假定 Gemini CLI 的免费登录仍可用。
5. Aider：把每次修改与 Git 历史紧密绑在一起
Aider｜MIT｜主要形态：终端、Git 原生的代码助手
Aider 的特点很明确：它长期围绕现有代码文件、Git 差异和版本提交来组织 AI 修改，而不是先建一个庞大的自主 Agent 工作台。对于小范围但风险不低的改动，这种克制反而很实用。
比如我只允许修改导出分页的两个函数，并希望每一步都可以用 Git 检查。Aider 的 Git 优先思路能让我快速看到哪些文件变了、为什么变、如何撤销。模型仍然可能写错代码，但 Git 历史提供了更清楚的复核与回滚路径。
如果任务要牵涉云端部署、浏览器自动化、多 Agent 并行和长期无人值守，它不一定是最合适的完整平台。Aider 更适合重视增量修改、终端习惯和审查透明度的开发方式。
6. Cline：让开发者保留对高风险动作的明确确认权
Cline｜Apache-2.0｜主要形态：IDE Agent，也提供 CLI 与 SDK 入口
Cline 的设计最容易从“控制感”理解。它允许模型提出读文件、编辑文件和执行命令的动作，同时强调将关键操作呈现给开发者审查。比如 Agent 认为需要删除旧的 PDF 缓存目录，开发者可以先看清为什么删、影响哪些项目，再决定是否批准。
对接触陌生仓库的人，这种有明确批准步骤的执行方式能够减少误操作风险。它并不让模型推理更准确，但降低了错误动作直接落到文件系统的概率。
代价是长任务可能频繁停下来等待确认。Cline 的合适位置是想保留 IDE 和人工审查、又希望 Agent 能真的调用工具，而不是追求无人值守的最高自动化程度。
7. Roo Code：在开放 IDE Agent 上细分工作模式
Roo Code｜主要形态：开源 IDE Agent，源于 Cline 生态
Roo Code 值得研究的地方，是它把不同的 Agent 工作方式做成可配置模式。真实开发里，“解释项目结构”“排查 Bug”“修改代码”“审查结果”需要的工具权限并不相同。研究阶段只读就够，执行阶段才允许写文件，最后由独立审查步骤确认。
自定义模式增加了灵活性，也增加了维护配置的成本。分析阶段只读、确认影响范围后再开放写权限，是值得验证的一种用法；模式命名与提示词不能代替版本实际提供的审批和隔离机制。
8. Goose：把外部能力做成可组合的扩展
Goose｜Apache-2.0｜主要形态：开源、扩展驱动的本地 Agent
Goose 更像一个可以逐渐装配能力的通用工作台。除了读写代码，它强调通过扩展连接外部工具与系统。假设 PDF 问题必须先查任务记录、数据库和构建日志，而这些资料不在 Git 仓库里，扩展式 Agent 的思路就很有用：让不同系统的数据通过受控工具进入同一处理过程。
我喜欢这种设计，是因为它把“模型知道什么”和“系统允许它访问什么”分开了。每装入一个扩展，就相当于扩大一次工具边界；用起来方便，权限面也随之扩大。
所以评估 Goose 不只是看支持多少扩展，更要看扩展来源、凭据范围、日志留存，以及是否允许 Agent 对外部系统执行写操作。对需要跨多个服务处理任务的开发者，它比单纯代码补全更值得研究。
9. Zed Agent：编辑器性能与原生 Agent 体验一起设计
Zed｜主要形态：开源编辑器，内置 Agent 能力
Zed 首先是一款编辑器，其 Agent 能力是在编辑器交互中形成的，而不是把另一个独立 CLI 原封不动塞进窗口。对于需要大量导航、查看符号定义和逐段检查修改的人，编辑器响应速度、面板组织和代码视图是切实的生产力因素。
需要大量比对入口函数、共享变量和调用者时，Zed 的编辑器与 Agent 协同值得观察；它能否胜任长任务仍须单独验证。如果手里已有高度定制的 VS Code 或 JetBrains 工作流，还要算清插件、调试、协作和语言生态的迁移成本。
10. Continue：跨 IDE 的既有实现，先确认维护状态
Continue｜Apache-2.0｜主要形态：开源 CLI、VS Code 扩展与 JetBrains 插件；官方仓库已转为只读
有些团队已经按语言、插件和调试工具选好了 IDE，不想因为加入 Agent 就重建开发环境。Continue 曾用 CLI、VS Code 扩展与 JetBrains 插件覆盖这类需求，也留下了可查看、可修改的实现。但官方仓库现在明确标为只读，并将 2.0.0 称为最终版本。 选型时必须把这一状态与仍在迭代的项目区分开。
如果公司一半开发者用 VS Code，一半用 JetBrains，Continue 的既有版本仍可用来研究跨编辑器的规则、模型接入和上下文配置；但要把它推广为新的长期团队标准，就得自行承担兼容、安全修复和后续维护。官方仓库还建议 JetBrains 用户优先考虑 Continue CLI，而不是插件。
这正说明开源清单不能只看许可证和历史功能。项目是否仍维护，会直接改变团队的采用成本。
另外，研究和工程实践中还有 OpenHands 和 SWE-agent。前者偏开放的软件开发 Agent 平台与执行环境，后者以自动解决仓库 Issue、工具交互与评测见长。要做公开复现实验或研究故障修复轨迹，可以把它们纳入候选；它们与日常 IDE 的目标并不完全重叠。
04 四个国内开源项目分别解决什么问题
Qwen Code 和 Kimi Code CLI 面向终端开发，DeepSeek Harness 开放运行时组合能力，Trae Agent 更适合软件工程任务研究与评测。它们可以与 OpenCode、Pi、Codex CLI 按职责交叉比较，不能只用模型产地划分。
1. Qwen Code：从模型生态走向可配置的开发执行器
Qwen Code｜Apache-2.0｜主要形态：开源 Coding Agent、终端与程序化接入
Qwen Code 的主线不是把 Qwen 模型简单放进一个终端聊天框，而是让它能够阅读仓库、调用工具、修改代码、运行测试，并把开发者的项目指令纳入持续会话。项目提供不同模型和服务的连接能力，也逐渐形成了工具扩展、Skills、MCP、子 Agent 等开发机制。官方文档还给出了 Plan、审批、Auto-Edit 等不同权限模式，适合按任务风险逐步开放操作范围。权限文档
假设要比较 Qwen 系列与另一款兼容模型在 PDF 缺页任务中的表现，Qwen Code 可以尽量保持同一套工具和仓库环境，只调整模型端。这比同时换掉模型和 IDE 更有解释力。若让子 Agent 分别调查分页逻辑与测试覆盖，还必须核对父会话与子 Agent 的实际生效权限；配置成“只读”不能只看子 Agent 名称或提示词。
需要注意，模型可以配置多个并不保证任意模型具备同样的工具调用稳定性；权限模式也不等同于真正的操作系统沙箱。对重视国产模型适配、开源可审查性和 CLI 工作流的开发者，它与 OpenCode、Codex CLI 应当进入同一轮比较，而不是单独归为“国产替代品”。
2. Kimi Code CLI：把连续开发任务放在终端会话中
Kimi Code CLI｜MIT｜主要形态：开源终端 Coding Agent
Kimi Code CLI 可以读写工程文件、运行 Shell、搜索仓库和网页，再根据结果决定下一步操作；它不只是“把模型接进终端”，而是具备完整工具调用与反馈链路。官方仓库提供会话继续、交互审批、配置、IDE 协议接入等功能说明，适合习惯 Git、SSH 和命令行的开发者。官方命令文档
比如 PDF 导出故障连续查了两个小时，已经排除缓存因素、确定问题发生在异步写页，我希望第二天继续，而不是让新会话重新理解整个仓库。这时会话状态与续接能力就比“一次性生成代码的速度”更重要。再比如我希望在终端中直接跑项目测试、收集报错、再改代码，它和 Pi、Claude Code 属于可以拿同一套任务对比的产品形态。
这里要分清新旧名称：早期 Kimi CLI 的归档与后续 Kimi Code CLI 的开发需要按各自仓库和版本判断，不应继续套用旧教程。评估时仍要检查认证、模型兼容接口、操作审批，以及复杂任务有没有真正的停止条件。对于终端优先的个人开发，Kimi Code CLI 是值得认真试的国内开源选项。
3. DeepSeek Harness：把执行系统本身拆成可替换插件
DeepSeek Harness｜MIT｜主要形态：插件化 Agent Harness Runtime，当前以开发者预览定位
DeepSeek Harness 最值得关注的不是给定一个任务它能写多少代码，而是它的 Cordis 和 Everything is a Plugin 设计。它试图把模型接口、工具、会话、循环、持久化和界面都做成可组合部件。与在现成 Agent 上安装 Skill 不同，这种架构让开发者有机会直接调整运行时的组织方式。官方仓库
回到 PDF 场景，如果产品要求先走企业内部代码检索、再启动只读诊断、最后通过专用的 PDF 验证器才能结束，开发者可能需要更细粒度地改动工具调度、会话存储和执行节点。DeepSeek Harness 的研究价值就在这里：它更像用来搭建自己的 Agent 执行系统的底座，而不是首先优化“打开即用”的 IDE 体验。
但这个项目的限制必须讲清楚。官方明确标注开发者预览，存在不兼容更新；安全说明也指出尚未接受安全审计，不应视为生产环境安全隔离方案。安全说明。因此我会先用脱敏仓库、容器和最小权限研究架构，不会因为它开源或提供审批功能，就直接让它接触生产凭据。
4. Trae Agent：围绕可研究、可评测的软件工程 Agent
Trae Agent｜MIT｜主要形态：面向软件工程任务的开源 Agent 与 CLI
Trae Agent 与 TRAE IDE 名字接近，但目标不能混为一谈。开源 Trae Agent 强调透明、模块化、可以修改和分析的实现方式，面向软件工程任务执行、工具调用和不同模型配置，也更方便做消融研究与行为评测。它有独立仓库和技术报告，是一套可研究的 Agent 工程项目，不等于把整个 TRAE 商业 IDE 开源出来。
例如我想回答一个很实际的问题：当 Agent 修复 PDF 缺页时，性能改进究竟来自模型本身，还是来自更好的工具选择与上下文管理？可以固定问题样例，在 Trae Agent 上调整执行配置、保留每轮工具轨迹，再对照测试通过率与无效工具调用数量。它更适合这种可解释的研究，而不只是看一段产品演示视频。
对项目开发而言，它可作为自行扩展软件工程 Agent 的基础，但需要承担依赖升级、运行配置和测试基础设施的成本。如果目标只是立即交付网页，TRAE IDE 这类产品型入口可能更直接；如果目标是改执行策略或做标准化评测，Trae Agent 更值得研究。
四个国内项目放在一起，方向已经很清楚：Qwen Code、Kimi Code CLI 更接近日常终端开发成品；DeepSeek Harness 更偏底层 Runtime 设计；Trae Agent 更偏软件工程 Agent 研究与实验。 这与海外 OpenCode、Pi、Codex CLI、OpenHands 等形成的是交叉对应，而不是截然不同的两条技术路线。
05 国内商业产品：编程入口与通用工作台
商业产品侧，国内厂商也不再只是把代码补全放进编辑器，而是开始覆盖需求理解、任务分解、工具执行、测试、审查和交付。除了面向仓库开发的产品，WorkBuddy、豆包工作这样的通用工作台也能承接部分开发任务，但选型时不能把它们和专业 Coding Agent 当成同一种入口。对外提供模型、Agent API 或插件，也不代表产品级 Harness 全部开源。
1. TRAE：把“从需求到产物”放进 Agent 工作台
TRAE / SOLO 模式｜主要形态：Agent 导向的 AI IDE 与任务工作台
TRAE 适合从一个看得见的开发目标开始。比如“做一个能上传图片、设定纸张、导出 PDF 的网页工具”，用户给出要求之后，Agent 可以围绕页面、代码、构建和预览推进工作。SOLO 模式强调任务拆分与端到端交付，比纯粹的代码补全更接近一个开发工作台。
不过，我会把“从零做工具”和“修一个大型旧工程”分开评估。前者只要页面能跑，第一印象就不错；后者考验的是能否找到历史调用链、维持原有行为并留下回归测试。如果把 PDF 缺页任务交给 TRAE，我希望先看到调查结论、拟修改模块和已有功能保护清单，而不是直接重写一套新的导出功能。
TRAE 的价值在于可视化任务推进和结果预览；它的局限不是必然生成质量差，而是预览成功无法替代工程质量证明。使用商业 IDE 时，还要检查代码同步、模型调用、离线可用性和企业数据策略。TRAE IDE 与开源 Trae Agent 应分开判断。
2. 腾讯 CodeBuddy：从代码开发扩展到设计、文档和任务协作
CodeBuddy IDE｜主要形态：IDE、插件及 Agent 工作流
CodeBuddy 的产品思路不止是让模型修改代码，而是把需求、文档、设计产物和代码开发放在相对统一的协作界面中。官方 CodeBuddy Agents 文档描述了多任务并行、变更文件视图、产物查看和预览，也区分面向代码的编程模式与通用工作模式。官方快速开始
在设计稿转前端页面的任务里，产物查看与预览很有用；在存量工程里，应重点检查它能否识别已有模块、根据测试失败继续修复，以及多任务并行时是否会产生文件冲突。模型可选范围、API 服务、私有化与权限策略可能随版本或企业方案不同，采购前要逐项确认。
3. Qoder / Qoder CN：强调计划、执行和任务委派的连续性
Qoder 产品家族｜Qoder CN｜主要形态：AI IDE、CLI 与任务工作台
Qoder 关注的不只是当前光标旁边几行代码，而是一个任务从理解、拆分到实际交付的过程。这样的定位特别适合边界能写清楚的开发工作：例如“保持原有导出 API 不变，修复分页错乱，补足三组回归样例”。开发者可以先审查任务计划，再让 Agent 处理实现，并在最后集中核对交付物。
和 TRAE 比较时，我不会只看两边生成的 UI 谁更漂亮，而会比较一项复杂任务在计划改变、测试失败或执行中断后能否保持连续。对含有多年历史代码的项目，先定位相关文件再动手，比生成一个崭新的示例工程更重要。
国内产品线名称也要看清楚。Qoder 与 Qoder CN 是不同产品体系，账号、任务和数据不互通；具体功能、服务区域和版本仍需分别核对。商业服务提供多种入口，不代表所有运行时源码开放，也不意味着不同账户的模型额度和安全策略相同。
4. 百度文心快码 Comate：在已有 IDE 和企业代码里推进 Agent 化
百度文心快码｜智能体文档｜主要形态：IDE 插件、AI IDE 与编程智能体
文心快码比较适合从既有开发环境和企业代码库切入。团队不一定想换编辑器，也不一定希望把代码交给一个完全独立的云端任务系统；它更需要的是项目理解、智能修改、测试和代码审查能力逐渐融入熟悉的 IDE。
比如导出 PDF 的问题涉及前端按钮、Java 服务、数据库记录和一份旧接口文档。评价这类工具不能只问能否补写某个方法，还要看它如何检索项目上下文、是否能准确跨文件定位、是否能控制变更范围，以及给出的修复建议能否经过单测和集成测试确认。
对企业来说，这种路线的真正难点是旧工程的复杂性：仓库规模、依赖版本、内部权限和流程集成都可能比生成代码本身困难。我会把文心快码放进存量代码库维护这一类任务与 Cursor、Copilot、CodeBuddy 一起试，而不是只做从零生成网页的演示。
5. 华为云码道 CodeArts：更接近企业研发治理与代码库工程
华为云码道 CodeArts｜主要形态：AI IDE、插件与 CLI，面向个人开发和企业研发场景
华为云码道已有 AI IDE、VS Code 与 JetBrains 插件以及 CLI 等入口；在大型存量仓库中，代码库索引与检索也是其产品重点。如果项目运行在有严格访问控制的团队环境中，选型还要问清Agent 能看到哪些代码、能执行什么命令、能否留存审计证据，不能仅凭产品页面上的“企业级”字样判断。
例如某个导出服务在内部网络运行，源码、构建产物和测试日志不能进入公共云环境。我会先问清楚部署形态、检索索引位置、模型调用的数据路径以及权限隔离，再去比较 Agent 能否定位分页缺陷。只有经过授权并能够保留审计记录，代码自动修改才可能进入正式研发流程。
这不是说企业级工具天然修复能力最强，而是它承担了消费级 Agent 不一定默认解决的组织要求。华为云码道是否满足某个单位的具体国产化、内网或私有化标准，仍须依据相应版本、部署方案和安全文档核验，不能从产品名称推断。
6. 腾讯 WorkBuddy：从办公任务延伸到代码开发
腾讯 WorkBuddy｜主要形态：覆盖办公、代码开发和设计任务的通用 AI 工作台
腾讯的产品矩阵里，CodeBuddy 和 WorkBuddy 都会碰到代码，但入口重心不同。CodeBuddy 围绕 IDE 中的项目理解、文件修改和变更审查；WorkBuddy 从自然语言任务出发，调用工具、处理获授权的本地文件，也提供前端等领域专家。要做一个小型页面或把资料整理、界面制作、代码生成接成一项任务，WorkBuddy 值得列入候选。若任务是维护多年历史仓库，仍要单独检验它能否定位调用链、控制 Diff、运行回归测试，而不能因为它能生成页面就推断它与 CodeBuddy 在代码库维护上等价。
7. 豆包：先分清豆包工作与豆包 MarsCode
豆包工作｜主要形态：面向多类生产力任务的 Agent 工作台；豆包 MarsCode｜主要形态：AI 编程助手与云端 IDE
只写“豆包”容易漏掉两个不同入口。豆包开放平台支持用技能、插件接入豆包工作，插件还可以封装 MCP 与 CLI；代码与应用交付是豆包工作可能承担的任务之一。MarsCode 则原本直接面向开发者，提供代码补全、解释、调试和云端开发环境。MarsCode 插件已更名为 TRAE Plugin，因此它与上文的 TRAE 有产品沿革关系，不宜在 2026 年的选型表里机械地算成两家互不相关的新产品。
如果目标是把多种资料和工具串成一个应用原型，可以观察豆包工作交付的代码能否导出、在本地重建并接入 Git；如果目标是在既有仓库持续改代码，应优先检验 TRAE 或同类开发工具的项目理解、测试反馈与变更审查。豆包使用的模型、豆包工作这个任务入口，以及 MarsCode／TRAE 的编程产品线，是三个不同层次，不能因为都带“豆包”或使用相关模型就合并比较。
06 其他不应混入 Coding Agent 排名的系统
通用 Agent 系统里还有 OpenClaw、AgentScope、Coze Studio 和 Dify。OpenClaw 偏多渠道个人助理；后三者主要面向 Agent 应用开发与编排。它们可以有模型路由、工具调用和持续流程，却不以 Git 仓库中的代码修改为共同中心任务。
比如“接收用户工单—检索知识库—生成答复—必要时升级人工”，Dify 或 Coze Studio 是自然的候选；要研究 Agent 的角色协作和工具执行，AgentScope 可以提供开发框架；要在消息渠道发起受控任务或接收执行通知，可以考察 OpenClaw。若主要成果是定位 PDF 缺页、修改源码、执行测试和提交 PR，就应先选 Coding Agent。
这也解释为什么不能只凭产品名称包含“Agent”就混排：Coding Agent 的成果主要由可运行代码、测试、Diff 和审查记录证明；业务 Agent 平台更常由业务流程结果、接口行为、知识检索质量和人工接管机制来评价。 两者可以组合，但验收对象不同。
07 用三个开发任务检验候选
工具介绍到这里，其实可以开始缩小候选集了。我一般不会拿三十款产品全部跑一遍同一道题，而会按任务类型先筛选，再用相同约束评估最终进入短名单的产品。
场景 A：一个旧项目里的 PDF 导出缺页 Bug
任务特征：已有仓库、不可破坏现有功能、需要跨文件排错、结果必须由回归测试证明。
我会先选两到三款终端 Agent（比如 Claude Code、Codex CLI、OpenCode、Qwen Code 或 Kimi Code CLI），再选一到两款 IDE Agent（比如 Cursor、Cline、TRAE、CodeBuddy、Qoder 或文心快码）。不是说这些工具彼此完全同质，而是要分别回答两个问题：终端式连续执行是否更省反复指挥的时间？IDE 式逐段审查是否更有助于避免错误修改？
任务文本不必写得很长，但应有明确边界：
## 任务：修复 PDF 导出缺页
现象：同一项目连续导出 PDF，偶发缺页或页数不一致。
请先定位原因、复现问题，再执行最小修复。
必须遵守：
- 不删除现有导出格式和用户配置项
- 只修改 src/export/ 与 tests/export/（示例目录，按实际仓库替换）
- 先报告原因和拟修改文件，再实施变更
- 至少覆盖单页、多页、连续重复导出三个测试用例
- 执行现有测试；若环境缺失，明确报告，不能写"已通过"
- 完成后提交文件清单、Diff 摘要、测试结果和剩余风险
停止条件：无法复现、连续两次遇到相同阻断错误，或需要突破目录/权限边界时，暂停并询问。
一轮验收也不能只看 Agent 的结束文案。我会在仓库中独立检查：
# 以下命令以已经配置相应 npm scripts 的项目为例
# 按真实工程改成 pytest、cargo test、go test 等对应命令
git status --short
git diff --check
npm run typecheck
npm test
这几条命令检查的是变更痕迹、空白与补丁格式、静态类型以及项目现有测试。它们本身不能证明 PDF 缺页已经修好。 还必须由真正的回归测试断言输出页数、页面内容与连续导出的一致性。若原工程没有 PDF 回归测试，应先补上测试实现，并保留失败前后的输出证据。
这才叫示例兑现承诺：工具能宣称“修好了”，验收必须能证明它修好了。
场景 B：从零做一个能够上线的小工具
任务特征：需求相对清楚，但一开始没有现成仓库；需要快速搭建 UI、业务逻辑和预览环境。
这时候我会把 Replit Agent、TRAE SOLO、CodeBuddy、Qoder 与 Cursor 等放在第一组。它们在从需求到工程初稿的环节，更容易观察产品差异。相对地，Pi、DeepSeek Harness 或 Trae Agent 这类可定制执行框架不一定是最快的起步方式，因为我还要自己配置运行工具和产品界面。
WorkBuddy 和豆包工作也可以放进这一场景的补充候选，尤其当需求同时包含资料处理、页面生成和其他办公交付时。比较时要让它们提交同一份可运行工程，而不只看工作台里的预览；豆包 MarsCode 的插件沿革则放在 TRAE 产品线里核对，不重复计数。
不过对结果的要求不能停留在“预览长得挺好”。我会补一张验收卡：文件能否在本地重建、项目能否从空环境安装依赖、导出的 PDF 是否正确、异常输入如何提示、是否存在硬编码密钥、代码是否能独立迁移。这样就不会把产品演示和实际交付混成一回事。
场景 C：内部仓库和严格数据边界
任务特征：访问权限细、日志要留存、源码可能不能出内网，服务涉及云资源或企业内部接口。
这时先做环境与合规筛选，再比较 Agent 的编程能力。我会调查企业方案中的实际数据流向、可用沙箱、身份授权、审计记录和模型部署位置。国内可优先看华为云码道、文心快码、CodeBuddy、Qoder 的具体企业方案；海外同时比较 GitHub Copilot、Factory、Amazon Q Developer，以及可自行部署和修改的 OpenCode、Codex CLI、Qwen Code、DeepSeek Harness 等。
这里没有“开源一定通过、闭源一定不通过”的结论。开源 CLI 即使运行在本地，也可能把代码传给远程模型；商业工具如果具备符合要求的企业部署方案，也可能满足特定组织的边界。真正的验收证据应来自部署架构和实测日志，而不是营销标题。
08 开源与闭源，到底该从哪几个维度做取舍？
上面的三个场景，其实暴露的是同一组工程问题。选型时，我会把功能列表收敛成下面这张表。
| 判断维度 |
要实际验证什么 |
容易误判的地方 |
| 执行闭环 |
是否能搜索、修改、运行测试、读取失败并继续处理 |
支持 Agent 模式 ≠ 具备可靠验证 |
| 任务接口 |
IDE、CLI、云端委派，哪个符合团队习惯 |
同一模型在不同入口的体验不相同 |
| 项目上下文 |
对现有仓库、项目规则、历史状态的理解是否可靠 |
上下文窗口大 ≠ 总能检索到正确文件 |
| 权限与沙箱 |
文件写入、Shell、网络和密钥访问如何控制 |
请求确认 ≠ 强隔离；本地运行 ≠ 没有数据外传 |
| 变更审查 |
有无 Diff、测试日志、PR 和回滚路径 |
“已完成”不是验收证据 |
| 开放与可移植 |
核心仓库、扩展接口、模型路由和会话迁移 |
支持多模型 ≠ 模型间完全等价 |
| 执行成本 |
API 用量、订阅限制、机器和人工复核时间 |
免费框架 ≠ 免费运行；付费订阅 ≠ 无限使用 |
| 持续维护 |
社区活跃、版本兼容、企业支持和升级路径 |
GitHub Star 不是稳定性证明 |
我还会补一项常被省略的重复实验：同一任务至少跑几轮，记录成功率、所花时间、失败原因和人工介入次数。单次成功可能只是某一次随机路径比较顺；单次失败也可能来自模型限额、测试环境或权限配置。想评价 Harness 质量，需要尽量固定模型、仓库版本、任务描述、工具权限与时间预算。
对于实际使用者，没必要人人都做学术级 Benchmark，但至少不能只看一个宣传视频就把软件采购和数据安全决策定下来。
09 写在最后
整理完这份名单，我更确定一件事：产品能搜索、修改和运行命令，只是进入候选的起点。真正试用时，还要看它是否守住目录和权限边界，能否把失败留在记录里，以及改动能否经得起独立测试和审查。
先按任务选入口，再用同一仓库、同一约束和同一验收方法比较两三款候选。开源与否、产品来自哪里，会影响扩展、采购和部署选择；最终是否适合自己的团队，要看执行轨迹、代码差异与人工复核成本。更多 AI Agent 开发与选型讨论，欢迎到 云栈社区 交流。
官方入口与进一步阅读
海外商业工具
海外开源项目
国内开源项目
国内商业产品
通用 Agent 平台
发表于 1 小时前
|
查看: 5|
回复: 0
