人和 Agent 怎么一起干活：把任务交出去，把判断留在关键处

第一次使用 Agent 时，很多人会走向两个极端。

一种是盯着每一步操作：读哪个文件、改哪一行、运行什么命令，都要亲自安排。Agent 成了一个需要不断指挥的执行器。

另一种是直接交出一个大目标："把这个项目优化一下。"等它完成后才发现，改动很多，真正需要解决的问题却没有解决。

更有效的协作方式，是让人明确目标、约束和验收标准，让 Agent 在授权范围内完成调查、实现与验证，并在真正影响结果的节点上交换信息。

以软件开发为例，人和 Agent 一起干活，可以从下面几件事开始。

先把任务讲成一个结果，而不是一句愿望

"优化订单接口"是一句愿望。它没有说明当前问题，也无法判断什么时候算完成。

可以改成：

diff 复制代码

订单列表查询在指定测试数据下响应过慢。
请先定位耗时来源，再提出优化方案。

约束：
- 保持返回字段、筛选条件和排序语义。
- 不连接生产数据库，不直接执行索引变更。
- 不修改无关模块。

验收：
- 在相同数据和查询条件下比较优化前后的耗时。
- 确认查询结果一致。
- 说明验证环境及尚未覆盖的情况。

这样的任务给了 Agent 自主调查的空间，也让人能够检查最终结果。

人的重要工作，是明确业务上什么不能变、什么值得优化，以及哪些代价可以接受。这些信息往往无法仅从代码中推断出来。

分工按决策性质划分

人不需要包办所有思考，Agent 也不应承担所有决定。更实用的分工如下：

工作	人的主要责任	Agent 的主要责任
明确目标	确定业务问题和优先级	指出歧义与缺失信息
理解现状	补充背景和历史原因	阅读代码、追踪链路、整理证据
比较方案	决定业务取舍与可接受成本	提出方案，说明依据和影响
实施修改	明确授权范围	完成范围内的实现和必要调整
验证结果	确认验收标准符合实际需求	执行检查，报告结果与限制
发布上线	按团队流程作出发布决定	准备可审查的改动与发布材料

这张表不是固定岗位说明。对于低风险、规则清楚的任务，可以一次授权 Agent 完成实现和验证；对于涉及资金、权限或数据迁移的任务，就应在方案和执行之间设置更明确的检查点。

把授权边界提前说清楚

协作效率很大程度上取决于 Agent 是否知道哪些事可以直接做。

如果边界不明确，它可能频繁请求确认，也可能把"修复问题"理解成可以顺便升级依赖、调整接口和重构模块。

一份简单的约定就能减少这种摩擦：

复制代码

可以直接完成：
读取相关代码、修改目标模块、运行本地测试。

需要先讨论：
修改公共接口、新增依赖、调整数据库结构。

本次任务不包含：
生产操作、部署、对外发送消息。

边界明确后，Agent 应在范围内持续推进。正常的实现细节，例如变量命名和沿用现有工具方法，没有必要逐项交给人审批。

对于重要限制，还应使用实际权限、隔离环境和审批机制落实。文字约定可以指导行为，但不能替代系统控制。

沟通要发生在会改变方向的地方

Agent 每读一个文件都汇报，人会被大量消息打断；一直沉默到最后，又容易让错误方向持续太久。

有价值的进度更新应该说明发现和影响，例如：

已确认主要耗时发生在数据库查询。当前索引无法充分支持排序条件，接下来会比较索引方案和查询改写的影响。

而下面这种更新信息量很低：

正在分析，继续检查，马上完成。

人也应该给出具体反馈。

"这个方案不行"很难指导下一步。更有效的是：

不能通过缓存解决，因为这里要求查询最新余额。请继续分析 SQL，并保留现有实时性要求。

这条反馈补充了业务约束，Agent 就能据此调整方案。

把分歧变成可以验证的问题

人和 Agent 的判断不一致时，不必急着选择相信谁。

例如，Agent 建议增加联合索引，开发者担心写入成本。双方讨论的重点可以落到具体问题：

现有执行计划为什么效率低？
候选索引能减少哪些扫描或排序？
表的写入频率和更新方式是什么？
是否存在功能重叠的索引？
如何在测试环境比较收益与代价？

Agent 负责收集和整理证据，人结合业务负载作出取舍。

同样，Agent 不应因为人提出了某个猜测，就直接把它当成事实。更好的回答是："这个方向值得检查，目前证据支持哪些部分，还缺哪些验证。"

好的协作允许双方修正判断。

一次交付应当足够小，也足够完整

让 Agent 一次完成"整个系统重构"，往往难以审查。把工作切成几十个只改一行的小任务，又会增加沟通负担。

合适的任务单元，是一个能够独立验收的结果。

例如，"修复用户不存在时的异常"可以包含：

定位接口和调用链。
确认现有异常约定。
修改相关分支。
补充有意义的回归测试。
检查接口响应是否符合约定。

这比只交付一个代码片段完整，也比顺便重构用户模块更容易判断。

任务划分时，可以问一句：

这部分完成后，我们能否明确判断它已经解决了一个问题？

如果不能，可能还需要重新界定范围。

交付时，把证据放在结论旁边

Agent 说"已经完成"，应该对应一份可核对的交付说明：

复制代码

解决的问题：
用户不存在时，接口未按约定返回业务错误。

主要修改：
复用已有异常类型，补充缺失分支。

验证：
相关业务测试已运行并通过。

未验证：
当前环境缺少数据库，未运行数据库集成测试。

需要关注：
上线前仍需通过集成环境验证。

人审查时，也不必重新执行 Agent 的全部调查过程。应优先检查业务语义、关键差异和验证缺口。

尤其要区分三个状态：代码已经生成、检查已经执行、结果符合需求。它们不能相互替代。

任务变长时，维护一份共同认可的状态

跨多轮对话、跨天执行或中途交接时，双方容易对"已经决定了什么"产生不同理解。

可以保留一份短记录：

内容	示例
当前目标	降低订单查询耗时
已确认事实	主要耗时来自数据库查询
已作决定	保持实时查询，不引入缓存
当前进展	已形成两个候选方案
待解决问题	尚未比较写入成本
下一步	在测试环境验证候选方案

记录应随着关键决定和代码变化更新。恢复任务时，先检查这些信息是否仍然有效，再继续推进。

这份记录不需要复制完整聊天，它的作用是让人和 Agent 对当前工作保持一致理解。

人与 Agent 的协作可以从一个熟悉的小任务开始：人定义结果和边界，Agent 提交有依据的修改，人检查关键业务判断，再根据实际表现扩大委托范围。

当这种配合逐渐稳定，人就能减少对操作细节的管理，把更多精力放在目标、取舍和质量上；Agent 也能获得足够清楚的方向，持续完成可验证的工作。