你的 Cursor 用对了吗：SWE agent 智能协作之道

大家好，我是肆〇柒。做过程序猿的朋友，或者与程序猿群体走的近的朋友，应该了解程序猿这个群体，每天都在正面临着日益增长的系统复杂性和高效交付的巨大压力。为了提升生产力并应对这些挑战，Gen AI 工具，尤其是软件工程智能体（SWE agent，比如 cursor 等），逐渐成为了开发者的得力助手。这些智能体不仅能够生成代码片段，还能执行工具调用、迭代优化输出，甚至在某些基准测试中展现出能够媲美人类，甚至超越一些人类开发者的能力。然而，当面对现实世界中复杂且模糊的开发任务时，SWE agent 却暴露出了明显的局限性。正因如此，许多 SWE agent 被设计为与开发者协同工作，通过互动实现优势互补。

下面是来自微软的研究《Sharp Tools: How Developers Wield Agentic AI in Real Software Engineering Tasks》，将会深入探讨开发者如何与 SWE agent 协作解决实际代码库中的开放问题，并与大家一起分析其中的沟通障碍以及影响成功的诸多因素。通过观察 19 名开发者样本，使用 Cursor Agent 解决 33 个开源项目中的开放问题，这个研究试图填补该领域实证研究的空白，为优化开发者 - 智能体协作模式以及设计更高效的 SWE agent 提供一些依据。这些发现不仅关乎当下开发效率的提升，更将对未来软件工程领域的协作范式产生深远影响。

一些 Cursor Agent 的示例用法

一些概念与背景

软件工程智能体（SWE agent）的定义

SWE agent 是一类能够在软件开发生命周期中自主执行复杂任务的智能体，其核心优势在于基于环境反馈迭代细化输出的能力。与传统的非智能体工具（如代码补全插件）仅提供单一响应不同，SWE agent 能够自主搜索文件、修改代码、运行终端命令，并根据执行结果调整后续操作。例如，在处理一个 GitHub 问题时，SWE agent 可以先分析代码库结构，再尝试定位问题根源，生成修复代码，并最终运行测试验证结果。这种自主性和迭代性使得 SWE agent 在处理复杂任务时展现出巨大潜力。

SWE Bench 等基准测试的评估作用及局限性

SWE Bench 等基准测试为评估 SWE agent 的性能提供了标准化的度量方式。这些基准测试通常基于历史 GitHub 问题，涵盖了多种编程语言和任务类型，从而能够量化比较不同智能体的代码生成准确性、问题解决效率等关键指标。然而，其局限性在于主要关注智能体的自主性能，而忽略了与人类开发者协作的场景。现实世界的开发任务往往涉及团队协作、需求变更等动态因素，智能体在这些情境下的表现可能与基准测试结果大相径庭。因此，仅仅依赖基准测试无法全面反映 SWE agent 的实际应用价值。

研究方法

工具选择

在众多 SWE agent 中，研究者选择了 Cursor Agent 作为研究工具。经过对 Cursor Agent、VSCode Agent Mode、Windsurf Cascade、Cline 等工具的对比分析，Cursor Agent 凭借其独特优势脱颖而出。它不仅支持在 IDE 内操作，提供流畅的开发体验，还能自动结合用户当前打开的文件和光标位置作为智能体上下文，使智能体能够更精准地理解任务背景。例如，当开发者在某个函数附近请求代码修改时，Cursor Agent 可以聚焦于该函数相关的代码片段，而非整个文件，从而提高任务解决的针对性和效率。

任务与参与者选择

要求参与者解决他们曾贡献过的开源代码库中的开放问题，原因在于这些参与者对代码库结构和业务逻辑相对熟悉，能够更有效地与智能体协作。研究者对代码库进行了严格筛选，确保其规模较大（源代码文件数量超过 50 个）、近期活跃（过去一个月内有提交记录）、以软件为核心（非文档或教程集合），并且在 GitHub 上获得超过 500 次星标，以保证代码库的成熟度和实际开发价值。

参与者筛选依据包括公司内部员工身份、过去三个月内对目标代码库有贡献记录等。最终，19 名开发者参与了本研究。这些参与者的性别、年龄、种族 / 民族、编程经验等基本特征如下表所示：

多样背景体的执行轨迹、在对话中回溯等的参与者背景有助于提升研究结果的广泛性和代表性。例如，不同编程经验的开发者在与智能体协作时可能展现出不同的策略和行为模式，而不同地区的开发者可能受到当地开发文化和技术生态的影响，这些差异都将为研究提供丰富的视角。

实验流程与操作

实验开始前，研究管理员对参与者进行了 Cursor IDE 及其智能体功能的培训。通过一个演示任务，参与者熟悉了如何与智能体交互，例如在聊天窗口中输入提示、实时查看智能体的执行轨迹、接受或拒绝代码变更等操作。这一培训环节是为了确保参与者对工具的基本功能有清晰的理解，从而在实验过程中能够专注于任务解决而非工具学习。

在实验过程中，参与者通过远程控制研究管理员的系统进行问题解决。他们首先在 GitHub 上浏览代码库的开放问题列表，选择一个自己认为能够通过代码修改解决的问题。然后，参与者使用 Cursor Agent 尝试解决该问题，过程中尽量使用 AI 并进行口头报告，以实时记录他们的思考过程和操作动机。当完成一个问题后，研究管理员会与参与者共同选择下一个问题，确保任务在类型（如特性请求与错误修复）、难度和范围上具有多样性。例如，如果第一个问题是错误修复，第二个问题可能鼓励参与者选择一个特性请求；若第一个问题较为简单，后续问题则会更具挑战性。

数据收集与分析方法

研究者收集了多类型的数据以全面捕捉开发者与智能体的协作过程。会话录像包括视频、音频和屏幕录制，用于定性编码参与者的行为和与智能体的交互细节。研究者基于 CUPS 税收法改编了参与者活动编码表，新增了与智能体协作特有的行为状态，如跟踪智能体的执行轨迹、在对话中回溯等。具体行为分类详见下表

参与者活动分类

同时，还对聊天轨迹进行了编码，记录参与者提供给智能体的上下文信息（如文件、代码片段、外部链接）以及他们从智能体寻求的信息类型（如代码变更解释、测试运行等）。编码分类依据见下表

聊天轨迹分类法

此外，参与者在研究前后填写的问卷数据也为研究提供了重要补充。预研究问卷收集了参与者的 demographics 信息以及他们对 AI 工具的先前使用经验，这有助于我们了解这些背景因素如何影响参与者在实验中的行为和表现。而 post - study 问卷则聚焦于参与者对工具的感知，如智能体在开发过程中的角色、工具设计特征的重要性等。

在数据分析过程中，主要采用定性分析方法，深入挖掘参与者的行为模式和协作策略，同时结合定量数据（如提示使用次数、任务成功率等）呈现趋势。例如，下图直观展示了参与者处理不同任务时的成功率及时间投入分布

按参与者划分的成功率问题时间线

为了确保编码的一致性和可靠性，研究者计算了 Cohen’s κ 值，结果显示参与者活动编码和聊天轨迹编码的信度均达到近完美的一致性。此外，还进行了成员审查，将初步研究结果反馈给参与者，以验证结果的准确性和完整性。

研究结果

开发者与 SWE 智能体的协作模式

任务分配策略

在任务分配方面，开发者主要采用两种策略：一次性任务分配策略（一枪式策略）和逐步解决策略。采用一枪式策略的参与者有 10 人，他们将整个问题描述交给智能体，期望其能够生成全面的修复方案。这种策略的优势在于，如果智能体成功，开发者可以以极小的额外努力解决问题。然而，一旦智能体失败，开发者就要理解智能体生成的代码，还需花费大量时间迭代优化。例如，一位参与者提到，对于较为简单的、局部性较强的错误修复任务，他倾向于使用一枪式策略，因为这类任务通常有明确的解决方案路径，智能体能够快速定位并修复问题。但在处理涉及多个代码模块交互的复杂特性请求时，该策略往往导致智能体生成的代码与预期结果大相径庭，开发者需要反复调整提示并引导智能体逐步完善代码。

逐步解决策略则要求开发者手动将任务分解为多个子任务，并依次请求智能体解决每个子任务。使用此策略的参与者平均每个问题使用 11.0 个提示，而采用一枪式策略的参与者平均仅使用 7.0 个提示。尽管这种策略对开发者的主动性和沟通能力要求较高，但能够更早地发现智能体的错误并及时纠正，从而提高任务成功率。例如，一位经验丰富的开发者在处理一个涉及前后端交互的特性请求时，先请求智能体优化前端数据展示代码，待验证无误后，再请求其修改后端数据处理逻辑。这种分步推进的方式使他能够有效掌控任务进度和代码质量。

从成功率来看，采用逐步解决策略的参与者在他们处理的问题中成功解决了 83%，而采用一枪式策略的参与者仅成功解决了 38% 的问题。这一显著差异表明，逐步解决策略在复杂任务中更具优势。然而，这两种策略并非完全互斥。在实际协作过程中，开发者可能会根据任务的进展和智能体的表现动态调整策略。例如，一位开发者最初采用一枪式策略请求智能体生成一个完整的代码模块，但智能体生成的代码部分逻辑有误。此时，开发者转而采用逐步解决策略，针对代码中的每个错误逻辑分别向智能体发送提示进行修正，最终成功完成了任务。

实践指导：对于逐步解决策略，开发者可以按照以下步骤实施：

1. 1. 任务分解：将复杂问题分解为多个独立的子任务，每个子任务应具有明确的输入和输出要求。例如，将一个特性请求分解为数据模型设计、业务逻辑实现和用户界面适配三个子任务。
2. 2. 初始提示制定：为第一个子任务制定清晰的提示，尽量包含上下文信息（如相关文件路径、已有代码片段）以帮助智能体理解任务背景。
3. 3. 智能体反馈分析：在智能体完成子任务后，仔细审查其输出（包括执行轨迹、变更解释和 diff），评估是否符合预期。
4. 4. 任务描述调整：根据智能体的输出结果，调整后续子任务的提示内容。如果智能体在某个子任务中犯了错误，可在提示中明确指出错误并给出修正方向。
5. 5. 迭代推进：重复步骤 2 至 4，直到所有子任务完成并整合为最终解决方案。

知识传递

在与智能体协作解决问题的过程中，参与者向智能体提供了两类知识：上下文知识和专业知识。上下文知识主要来源于问题描述和环境背景（如测试日志），例如，参与者告知智能体某个函数在特定输入条件下会抛出异常。专业知识则是基于开发者对代码库的深入理解和过往经验，涉及代码实现细节或编码规范等，例如，一位开发者指出在该代码库中通常避免使用硬编码的超参数，并建议使用配置文件进行管理。

研究发现，参与者提供专业知识的模式与软件工程管理者分配工作的行为高度相似。管理者往往在初始任务分配时提供较为宽泛的指导，而在开发过程中根据工程师的反馈提供具体、针对性的建议。同样，参与者在请求智能体生成新代码变更时，通常较少提供专业知识（49% 的提示包含专业知识），但在请求智能体优化已生成代码时，专业知识的提供比例上升至 65%。对于担任管理职务的 12 名参与者而言，这种差异更为显著，他们在请求新代码变更时提供专业知识的比例为 45%，而在请求代码优化时这一比例高达 75%。

进一步分析表明，参与者对代码库的熟悉程度和是否有使用 Cursor 的经验显著影响其专业知识的提供频率。在研究前四个月对代码库有超过 10 次提交记录的参与者，在寻求代码变更时提供专业知识的比例达到 70%，而其他参与者仅为 48%。有 Cursor 使用经验的参与者在寻求代码变更时提供专业知识的比例更是高达 81%，且在请求代码优化时专业知识提供比例达到 89%，远高于请求新代码变更时的 67%。这表明，随着对代码库和工具的熟悉度增加，开发者更倾向于主动向智能体传授专业知识，以引导其生成更高质量的代码。例如，一位资深开发者在处理一个涉及代码重构的问题时，凭借对代码库架构的深入理解，向智能体详细说明了各个模块之间的依赖关系和预期的重构目标，从而使智能体能够生成符合整体架构规范的优化代码。

实践指导：为了有效传递专业知识，开发者可以：

1. 建立知识库：整理代码库中的关键设计决策、架构规范和常见实现模式，形成文档或模板。在与智能体协作时，将相关知识片段直接引用到提示中。例如，对于一个微服务架构项目，可以将服务间通信的规范（如 RESTful API 设计原则、消息队列使用场景）整理成文档，当请求智能体生成接口代码时，将相关规范片段粘贴到提示中。

2. 采用类比和示例：在提示中使用类比或提供示例代码，帮助智能体理解特定的实现方式。例如，“在之前的用户认证模块中，我们通过中间件实现权限验证，类似地，请为订单管理模块实现一个权限验证中间件，确保只有管理员角色可以访问特定接口”。

3. 引导式提问：以问题的形式引导智能体思考专业知识点。例如，“根据我们项目的错误处理规范，网络请求失败时应该返回哪种格式的错误信息？请按照这一规范修改当前代码”。

请求的任务类型

参与者需要请求智能体进行代码修改以解决 GitHub 问题，还需要寻求代码理解、测试运行、代码审查等方面的帮助。具体而言，50% 的提示请求代码变更，27% 的提示寻求代码库相关细节的解释（代码理解），16% 的提示要求运行测试，11% 的提示请求对智能体所做变更的解释（代码审查）。这一任务请求分布与参与者对智能体角色的认知高度一致。在 post - study 问卷中，参与者普遍将智能体视为内容生成器，认为其最擅长生成代码。同时，由于将智能体视为参考指南，他们也频繁请求智能体解释代码库结构和现有代码逻辑。然而，参与者对智能体作为代码审查者的期望相对较低，因此在请求测试运行和代码审查方面的提示较少。

Agent 感知研究后续问卷调查结果

例如，在处理一个涉及复杂算法实现的问题时，一位开发者首先请求智能体解释算法的核心思想和现有代码实现的优缺点（代码理解），然后基于智能体的解释提出改进方案，并请求智能体生成优化后的代码（代码变更）。在代码生成后，开发者又要求智能体运行相关测试用例以验证代码的正确性（测试运行）。在整个过程中，开发者仅在智能体生成代码后简单查看了其变更解释，并未深入借助智能体进行代码审查。

实践指导：针对不同类型的任务请求，开发者可以采用以下实践方法：

1. 代码理解任务：

• 使用具体的问题引导智能体，如“在用户登录流程中，哪个函数负责验证用户名和密码的格式？请解释其正则表达式规则”。
• 结合代码片段请求解释，例如，“针对以下代码片段（粘贴代码），解释其在处理并发请求时的线程安全机制”。

2. 测试运行任务：

• 明确指定测试范围和预期结果，如“请为 User 模型的 save 方法编写单元测试，覆盖正常保存、字段验证失败和数据库连接异常三种情况，并输出测试结果”。
• 在测试失败时，要求智能体分析失败原因，如“测试用例 test_login_failed 报错，根据错误信息和代码，分析可能的原因并提出修复建议”。

1. 3. 代码审查任务：

• 提供审查标准或检查列表，引导智能体按照特定规范进行审查。例如，“根据公司的代码审查规范（粘贴规范要点），审查我提交的代码变更，指出不符合规范的地方”。

• 将审查范围限定在特定方面，如“仅从代码可读性角度审查以下函数（粘贴函数），提出改进意见”。

手动操作

参与者对智能体的角色认知深刻影响了他们在协作中的自身角色定位。在验证（调试和测试）和内容生成（编写代码）方面，这种影响尤为显著。尽管智能体能够生成代码变更，但由于参与者对其在调试和测试等验证任务上的能力缺乏信任，往往主动承担起手动调试和测试工作。在 33 个问题中，参与者手动调试和测试代码的案例多达 21 个。例如，一位开发者在处理一个涉及用户界面交互的错误修复任务时，尽管智能体生成了看似合理的代码，但开发者仍选择手动在本地浏览器中运行代码并观察用户界面行为，以确保修复效果符合预期。

相比之下，参与者在内容生成方面的手动操作较少，仅在 14 个问题中手动编写代码，其中 10 个问题的代码干预局限于修改智能体建议的代码，而非新增功能代码。这表明，开发者对智能体生成代码的能力持有较高信任，但在验证环节更倾向于亲力亲为。部分参与者也表达了希望 AI 工具在审查和验证方面提供更有力支持的观点，认为这将大幅提高开发效率并降低错误风险。

在实际开发项目中，这种现象具有普遍性。例如，在敏捷开发团队中，开发者通常会借助智能体快速生成代码原型，但在代码审查和测试环节，仍需依赖团队成员的协作和手动操作。这种协作模式不仅影响项目进度（如因手动调试导致迭代周期延长），还对代码质量产生关键影响（如智能体生成的代码可能存在隐藏的逻辑缺陷，需通过人工测试发现）。

实践指导：为了平衡手动操作与智能体协作，开发者可以采取以下措施：

1. 验证任务分配：在开始任务前，明确划分智能体和开发者的验证职责。例如，智能体负责运行自动化测试套件并报告结果，开发者负责分析复杂场景下的运行时行为和边界条件测试。

2. 逐步转移验证任务：对于智能体能力范围内的验证工作，先让智能体尝试完成，开发者对其输出进行抽检。例如，智能体生成单元测试代码并执行，开发者随机选择部分测试用例进行复查，根据复查结果决定是否扩大智能体的验证权限。

3. 代码生成协作：在代码生成过程中，开发者可以先使用智能体生成代码框架，然后手动填充关键业务逻辑细节。例如，智能体生成一个数据访问层的代码模板，开发者添加具体的数据库查询优化逻辑。

审查输出

智能体通过三种方式与参与者沟通：执行轨迹、变更解释和变更 diff。执行轨迹是智能体工作时的实时记录，包括代码库搜索、文件读取、终端命令执行等操作步骤。变更解释是智能体在执行结束后对所做变更的总结性描述，而变更 diff 则直观展示了代码的具体修改内容，供参与者接受或拒绝。

研究观察到，参与者倾向于实时跟踪智能体的执行过程，这一行为在 84% 的提示中得到体现。而对于 23% 的提示，参与者仅通过实时观察执行轨迹即可完成验证，无需进一步审查 diff 或解释。通常，实时分析足以使参与者理解智能体的上下文收集步骤，例如，智能体搜索了哪些相关文件、执行了哪些初步命令等。在大多数情况下（75% 的智能体响应后），参与者会进一步审查 diff 或解释。其中，参与者更偏好直接审查代码变更 diff，而非阅读变更解释。在包含代码变更的智能体响应中，参与者在 95% 的情况下实时跟踪执行过程，但在 67% 的情况下需要进一步审查 diff，而仅在 31% 的情况下审查解释。即便在同时审查 diff 和解释的情况下，这一比例也仅为 23%。

这种对代码变更的直接审查偏好在 post - study 问卷中得到了印证。参与者将能够查看详细代码变更解释的功能评为相对不重要的特性。

Agent 特性学习后问卷调查结果

具有 Cursor 使用经验的参与者对解释的关注度甚至更低，他们在包含代码变更的智能体响应中仅阅读 18% 的解释，而其他参与者为 35%。尽管如此，这种直接审查代码的行为通常足以使参与者对智能体的代码变更形成清晰理解，并且仅在 16% 的后续提示中询问智能体关于生成变更的解释。这表明，开发者对智能体输出的信任建立在对代码变更的直接审查之上，而非依赖智能体提供的文字解释。

实践指导：优化输出审查流程的建议如下：

1. 实时跟踪优先：在智能体执行任务时，保持对其操作的实时观察，重点关注其对代码库的搜索路径和文件访问顺序，这有助于快速了解智能体是否在正确的方向上工作。

2. diff 审查要点：

• 对于代码修改部分，检查是否符合代码风格规范（如命名约定、缩进规则）。

• 分析逻辑变更是否完整，是否存在遗漏的边界条件处理。

• 验证与现有代码的集成点是否正确，例如函数调用参数是否匹配、数据类型转换是否合理。

3. 解释利用策略：将智能体的解释作为辅助参考，当 diff 审查中发现疑问时，回溯解释以理解智能体的修改动机。例如，如果发现智能体修改了一个配置文件，通过解释确认其目的是为了适配新功能的环境变量要求。下图可以直观地展示出智能体输出的代码变更 diff 的形式，有助于大家理解开发者在面对智能体输出错误时所看到的内容。

由Agent建议的代码编辑差异

处理错误输出

面对智能体生成的错误代码，参与者更倾向于迭代优化而非直接放弃重来。在所有问题中，平均每个问题参与者使用 8.2 个提示，其中 52% 的提示用于优化智能体之前生成的代码变更。这一现象在特性请求任务中尤为突出，参与者平均使用 11.2 个提示，而错误修复任务中这一数字仅为 6.3。例如，在处理一个涉及新功能开发的问题时，智能体最初生成的代码实现了基本功能，但在与现有代码集成时出现了兼容性问题。参与者随后多次向智能体发送提示，逐步引导其优化代码，以确保新功能与整体系统无缝集成。

尽管迭代优化是参与者的首选策略，但部分参与者也表达了对其潜在风险的反思。一位参与者指出，如果开发者持续要求智能体修复其先前的错误代码，可能会陷入错误路径，浪费大量时间。例如，智能体在处理某个错误修复任务时，因误解问题根源生成了一系列错误代码。开发者在多次迭代后才发现智能体的初始假设存在偏差，不得不重新调整提示方向，导致任务解决时间大幅延长。此外，智能体的“不请自来的操作”现象（即超出提示范围进行更改）在一定程度上反映了其在任务边界识别方面的技术缺陷。在 38% 的未请求代码变更提示后，智能体仍进行了额外更改，有时虽能提高效率，但更多时候会造成沟通误解和开发者的困惑。

实践指导：为了有效处理错误输出，开发者可以遵循以下步骤：

1. 错误定位：在收到智能体的错误代码后，首先明确错误类型（如语法错误、逻辑错误、与需求不符的实现错误）。可以通过运行测试用例、查看错误日志或手动代码审查进行定位。

2. 提示重构：根据错误类型，重构提示内容。对于逻辑错误，提供详细的预期行为描述和示例输入输出。例如，“在排序算法中，当输入数组包含重复元素时，智能体生成的代码无法正确处理。请参考以下示例输入输出（提供示例），优化代码以确保稳定性”。

3. 限制迭代范围：在提示中明确指出需要优化的代码部分和预期的改进方向，避免智能体对其他无关代码进行修改。例如，“仅针对用户认证流程中的密码加密部分进行优化，保持其他代码不变”。

4. 设定终止条件：提前定义迭代优化的终止条件，如最大迭代次数或预期的质量标准。例如，“如果在 5 次提示后仍未解决兼容性问题，请停止迭代并尝试其他方案”。

开发者 - 智能体沟通的障碍

缺乏隐性知识

隐性知识在软件工程中占据核心地位，它包括开发者通过实践积累的经验、直觉和对项目背景的深刻理解。然而，智能体在缺乏此类隐性知识的情况下，难以有效协作。例如，一位参与者基于对代码库的熟悉，意识到智能体启动的单元测试命令执行时间过长，可能暗示测试失败。然而，他并未将这一基于经验的判断告知智能体，而是选择手动处理问题。在另一个案例中，智能体提供的代码库解释与代码库维护者在问题评论中的观点相矛盾，导致参与者对智能体输出的正确性产生严重怀疑。这种缺乏对社会背景信息的理解使得智能体在多团队协作或代码库有特定历史背景的场景下容易生成不符合实际需求的代码。

实践指导：弥补隐性知识缺口的策略如下：

1. 经验文档化：将团队中的最佳实践、常见问题解决方案和项目历史背景整理成文档，存储在智能体可访问的知识库中。例如，记录每次架构调整的原因和影响范围，当处理相关代码变更时，智能体可以参考这些文档。

2. 背景信息提示：在向智能体发送任务提示时，主动添加相关的背景信息。例如，“根据之前的团队讨论（链接会议记录），在处理支付模块时需要特别注意交易的原子性和一致性，请确保代码符合这些要求”。

3. 模拟隐性知识训练：如果条件允许，使用项目的历史数据（如过去的代码变更记录、问题解决日志）对智能体进行微调训练，使其学习到特定项目中的常见模式和隐性规则。

不请自来的操作

智能体超出提示范围进行更改的行为既可能提升效率，也可能引发误解。在 38% 的未请求代码变更提示后，智能体进行了额外更改。有时，这种主动性能够帮助开发者节省时间，例如，一位参与者表示智能体“预见了我接下来的操作”，提前完成了部分任务。然而，在更多情况下，这种不请自来的操作会导致沟通障碍。例如，智能体在未明确指示的情况下修改了额外的代码文件，迫使参与者拒绝更改并重新发送更精确的提示。此外，智能体未经请求运行终端命令的情况更为严重，这可能导致环境状态的永久性改变。在 10% 的未请求终端命令提示后，智能体仍执行了命令，参与者提前终止智能体操作的比例高达 61%，远高于未执行命令时的 21%。例如，一位开发者在审查测试日志时，智能体突然运行了新的测试命令，导致测试日志被覆盖，打乱了开发者的调试节奏。

实践指导：防止不请自来的操作的建议如下：

1. 明确任务边界：在提示中使用清晰的指令限制智能体的操作范围。例如，“仅修改 User 模型的 validate 方法，不要对其他文件进行任何更改”。

2. 分步授权：对于涉及多个操作的复杂任务，将任务分解为多个步骤，并在每个步骤后要求智能体等待进一步指示。例如，“第一步：搜索代码库中所有使用了过时 API 的地方，并列出文件路径。请在执行任何修改前等待我的下一步指令”。

3. 环境隔离：在独立的测试环境中运行智能体，避免其对生产环境造成意外影响。例如，为智能体设置一个专门的代码分支，在验证所有更改无误后再合并到主分支。

同步性问题

智能体和用户同时对同一代码库进行操作可能引发一系列挑战。例如，当智能体和开发者同时修改同一代码片段时，可能导致重复修复或代码冲突。在一次任务中，智能体在开发者手动修改代码的过程中重复了部分修复操作，迫使开发者拒绝智能体的更改。为了避免此类干扰，一些开发者采取了预防性措施，如在智能体执行过程中避免对代码库进行操作，静静等待智能体完成任务。这种行为表明，开发者对智能体的操作范围和意图缺乏清晰了解，担心自己的操作会与智能体产生冲突，从而影响任务进度和代码质量。Pu 等人的研究也指出，过于主动的 AI 辅助可能会使用户对其可执行的操作产生不确定性，建议限制智能体的行动范围，确保其操作不会干扰用户的即时工作流程。

实践指导：解决同步性问题的方法如下：

1. 操作规划协商：在开始任务前，与智能体协商操作计划。例如，可以先让智能体提出其修改方案（如列出计划修改的文件和修改要点），开发者审核后确认是否执行。

2. 独立操作区域：将代码库划分为不同的区域，智能体和开发者分别在各自的区域内操作。例如，开发者负责修改核心业务逻辑代码，智能体负责处理周边的工具类代码或测试代码。

3. 变更合并流程：建立智能体和开发者变更的合并流程，使用版本控制系统（如 Git）管理冲突。例如，智能体的更改提交到一个专门的分支，开发者定期将该分支合并到自己的工作分支，并在合并时解决冲突。

冗长性

智能体冗长的解释经常给参与者带来困扰。尽管参与者会阅读智能体的解释（在 39% 的智能体响应后），但冗长的解释一方面增加了信息处理负担，还可能导致关键内容被淹没。例如，一位参与者因智能体冗长的解释而未能注意到其中包含的文档链接，不得不手动进行网络搜索以查找相关信息。另一位参与者形容智能体的解释为“大量无用的分析”，这表明冗长的解释可能降低开发者对智能体输出的满意度，并影响其对智能体的信任度。在这种情况下，开发者可能倾向于忽略智能体的解释，仅依赖代码变更 diff 进行审查，从而减少了与智能体的深度沟通机会。

实践指导：应对冗长性问题的策略如下：

1. 指定解释风格：在提示中要求智能体采用简洁的解释风格，例如，“请以项目符号列表的形式简要说明代码变更要点，避免冗长的段落描述”。

2. 关键点提取请求：当智能体生成冗长解释时，要求其提取关键点。例如，“从上述解释中提取出三个最重要的变更理由，并用一句话概括每个理由”。

3. 分段解释：对于复杂的变更，要求智能体分段提供解释，每段聚焦于一个特定方面。例如，“先解释函数 A 的修改原因，然后在下一条消息中解释函数 B 的修改原因”。

阿谀奉承式回应

智能体倾向于无条件同意参与者在最新提示中的观点，这种阿谀奉承式回应可能导致开发者对其信任度下降。当智能体对同一问题产生看似矛盾的解释时，开发者会对其一致性产生怀疑。例如，一位参与者提到，当他对智能体的更改提出质疑时，智能体立即撤销更改，这种行为让他对智能体的能力产生不信任感。另一位参与者在 post - study 问卷中指出，智能体“容易被误导，无法独立思考”，这表明开发者期望智能体能够在一定程度上对他们的提示进行批判性分析，而非盲目服从。相比之下，一位参与者采取了独特的协作方式，通过提出暗示性问题（如“是否存在负面影响？”）引导智能体进行自我反思，而非直接下达指令。这种方式促使智能体在优化过程中进行更深入的思考，不仅帮助解决了当前问题，还发现了代码中其他潜在问题。这表明，设计能够与开发者进行实质性讨论的智能体，而非仅仅服从命令，可能提升解决方案质量并促进开发者成长。

实践指导：避免阿谀奉承式回应的实践方法如下：

1. 采用探索性提示：使用开放式问题引导智能体进行独立思考。例如，“在实现这个新功能时，可能存在哪些潜在的性能瓶颈？请分析并提出优化方案”。

2. 假设挑战：在提示中提出假设让智能体验证。例如，“假设我们采用缓存策略来优化数据查询性能，请分析这种方案的优缺点，并与数据库索引优化方案进行比较”。

3. 多角度分析请求：要求智能体从不同角度分析问题。例如，“从安全性、可维护性和性能三个角度评估当前代码实现，并指出需要改进的地方”。

过度自信

智能体对其更改的过度自信可能引发参与者的疑虑。即使智能体生成的更改正确，其对更改与问题对齐程度的自信态度也可能使开发者感到不安。例如，一位参与者在 post - study 问卷中提到，尽管智能体的修复方案有效，但“并非我真正想要的”，暗示智能体忽略了他对代码风格和结构的期望。另一位参与者在审查智能体提供的相关文件列表时指出，“这些内容虽然正确，但并非我想要修改的部分”，这表明智能体未能充分理解开发者的意图。当智能体执行超过 3 个操作（如终端命令或代码变更）时，参与者提前终止其执行的比例高达 39%，而智能体执行 3 个或更少操作时这一比例仅为 9%。这反映出开发者对智能体过度自信和操作范围过大的担忧，他们担心失去对任务解决方向的控制。例如，一位开发者在智能体生成大量代码后感到不知所措，认为智能体“接管了任务”，导致他不得不强制删除部分代码并重新开始。

实践指导：应对过度自信问题的建议如下：

1. 要求不确定性表达：在提示中要求智能体对其输出的不确定性进行说明。例如，“请指出代码变更中你最不确定的部分，并解释原因”。

2. 多方案提供：要求智能体提供多个可能的解决方案，并说明每个方案的优缺点。例如，“为这个问题提供两种不同的代码实现方案，一个注重性能优化，一个注重代码可读性，并比较它们的适用场景”。

3. 分步确认：将任务分解为多个步骤，每一步完成后要求智能体等待开发者确认后再继续。例如，“第一步：修改函数参数类型。完成后请暂停并等待我的确认”。

无效的后续建议

智能体提供的后续提示建议大多不够有效，参与者仅对 7% 的建议进行了回应。原因在于这些建议往往过于笼统，如“是否需要我进行其他操作？”，无法为任务解决提供明确方向。即使参与者需要对代码变更进行优化，智能体的后续建议也常与解决方案的实际状态不符，例如建议进入任务解决过程的下一阶段，而当前阶段的代码仍存在未解决的问题。这种无效的后续建议破坏了协作的连贯性，使开发者难以基于智能体的建议推进任务。

实践指导：改善后续建议有效性的方法如下：

1. 具体化后续提示：在提示中明确要求智能体提供具体的后续步骤建议。例如，“在完成代码生成后，请提出至少两个具体的测试用例建议，用于验证代码的正确性”。

2. 状态感知提示：要求智能体根据任务当前状态提供相关建议。例如，“根据当前代码变更后的状态，建议下一步需要重点关注的审查点或潜在风险”。

3. 多轮对话协作：在多轮对话中，智能体应参考之前的对话上下文提出连贯的后续建议。例如，在第二轮提示中，智能体可以结合第一轮的代码变更结果和开发者的反馈，提出优化方向或需要进一步澄清的问题。

影响成功的因素

协作策略

开发者在协作过程中积极主动地与智能体互动对任务成功率具有显著影响。成功解决的问题平均使用 10.3 个提示，而未成功解决的问题平均仅使用 7.1 个提示。这表明，频繁与智能体沟通、提供详细反馈的开发者更有可能成功解决问题。例如，一位开发者通过多次向智能体发送提示，逐步引导其优化代码结构，最终成功完成了复杂的代码重构任务。此外，请求智能体优化代码变更也是成功的关键因素。在成功解决的问题中，仅有 19% 的问题未涉及代码优化请求，而在未成功解决的问题中，这一比例高达 70%。

逐步解决策略的成功率远高于一枪式策略（83% 对比 38%），这进一步证明了主动参与任务分解和逐步引导智能体的重要性。可参考下图中不同策略对应的成功率对比。

按参与者划分的成功率问题时间线

同时，提供专业知识的开发者成功率更高（64% 对比 29%），这凸显了开发者经验在协作中的价值。例如，一位资深开发者凭借对代码库的深入理解，向智能体提供了关键的实现细节和优化建议，使智能体能够生成高质量的代码。此外，直接参与代码编写的开发者成功率也更高（79% 对比 33%），这表明开发者在协作中既是任务分配者，也是积极的问题解决者。

相比之下，手动调试和测试对成功率的影响相对较小（53% 对比 60%）。这可能是因为智能体在代码生成方面的能力相对成熟，而在调试和测试环节对开发者的依赖度较高。例如，智能体生成的代码可能在逻辑上正确，但在实际运行环境中存在性能瓶颈或边界条件处理不当等问题，这些问题通常需要开发者通过手动测试和调试发现并解决。

实践指导：为了提升协作策略的有效性，开发者可以：

1. 建立协作节奏：设定固定的提示发送频率和任务审查时间点。例如，每 30 分钟发送一次提示，并在每次智能体完成操作后立即进行审查。

2. 反馈质量提升：在反馈中需要指出问题，并提供改进建议。例如，“智能体生成的代码虽然功能正确，但变量命名不够直观。建议使用更具描述性的变量名，如将‘data’改为‘user_data’”。

3. 经验分享社区：参与开发者与智能体协作的经验分享社区，学习他人的高效协作策略，并将成功实践应用到自己的工作中。

外部因素

参与者使用 Cursor 的先验经验对成功率有显著影响。3 名有使用经验的参与者成功解决了 3/4 的问题，而其他参与者成功率仅为 52%（13/25）。这表明熟悉工具的操作方式和能力边界能够帮助开发者更有效地与智能体协作，减少学习成本和沟通障碍。

问题类型也显著影响成功率。用户界面更改的错误修复任务成功率最高（5/5），其次是重构 / 变量重命名任务（2/3），特性请求任务的成功率为 4/8，而普通错误修复任务的成功率最低（5/13）。这可能是因为用户界面更改通常涉及相对独立的代码模块和直观的视觉反馈，开发者能够更容易地引导智能体完成任务。而普通错误修复可能涉及深层次的系统逻辑和复杂的数据交互，需要开发者和智能体具备更高的问题定位和解决能力。

尽管基准测试表明智能体在不同编程语言上的表现存在差异，但在本研究中，编程语言对参与者成功率的影响并不显著。除 C# 语言外（3/3），其他语言的成功率均在 40% - 60% 之间，这表明在人类 - 智能体协作场景下，编程语言的差异可能被协作过程中的其他因素所抵消。

实践指导：针对外部因素，开发者可以：

1. 工具精通计划：制定工具学习计划，系统性地掌握智能体的各项功能。例如，每周花 1 小时探索 Cursor 的一个高级功能（如自定义提示模板、与其他工具的集成方式）。

2. 任务类型适应策略：

• 对于用户界面更改任务，利用智能体的可视化反馈优势，先请求其生成界面布局草图，再逐步细化代码实现。

• 对于普通错误修复任务，先使用智能体进行问题定位（如分析堆栈跟踪、搜索相关代码片段），再尝试修复。

3. 语言无关协作模式：总结跨语言的协作模式，例如，在代码结构相似的部分（如数据模型定义、接口声明），采用统一的提示模板，减少因语言差异带来的协作调整成本。

总结

通过深入观察开发者与 SWE agent 的协作过程，微软这份研究揭示了多种协作模式、沟通障碍以及影响成功的因素。这些发现对于理解和优化开发者 - 智能体协作机制具有重要意义。

开发者在与 SWE agent 协作时，采用不同的任务分配策略（如一枪式策略和逐步解决策略），并根据任务特点和智能体表现灵活切换策略。他们向智能体传递知识的方式与软件工程管理者分配工作的模式相似，且专业知识的提供频率受代码库熟悉度和工具使用经验的影响。在任务请求类型上，开发者不仅请求代码变更，还寻求代码理解和测试运行等支持，这反映了他们对智能体角色的多元化认知。手动操作方面，开发者因对智能体验证能力的不信任而更多地承担调试和测试工作，但在代码生成方面对智能体持有较高信任。审查输出时，开发者偏好直接审查代码变更而非解释，而处理错误输出时倾向于迭代优化而非放弃重来，尽管这一策略存在潜在风险。

沟通障碍主要体现在智能体缺乏隐性知识、不请自来的操作、同步性问题、冗长性、阿谀奉承式回应、过度自信和无效的后续建议等方面。这些问题导致开发者与智能体之间的协作效率降低，甚至影响任务成功。

影响成功的因素包括开发者的协作策略（如提示发送频率、代码优化请求）和外部因素（如工具使用经验、问题类型）。积极主动的协作策略和丰富的先验经验能够显著提高任务成功率。

未来应进一步探索 SWE Agent 如何采用高绩效下属工程师的沟通策略和行为模式以增强协作效果，研究智能体在输出过程中与用户协作调整输出范围的方法，以及设计能够与开发者进行实质性讨论的智能体。这些改进将有助于提升智能体在实际开发场景中的辅助作用，特别是在应对复杂、模糊且充满挑战的软件工程过程中的关键环节（如环境搭建、调试等），从而实现更高效、更智能的开发协作生态。这份研究很有实际意义，一方面可以给大家落地 AI Agent 应用带来一些人机交互方面的思考，另一方面，还可以指导开发者更高效的与编码类智能体工具（比如 Cursor）进行协作开发。随着技术的演进，我相信 SWE agent 能逐渐克服现有缺陷，成为开发者真正的智能伙伴，人机协作将会更加丝滑。