Uniquezx Weekly · 02：AI Agent 到底怎样才算真正落地？

一个需要人不断提醒、纠偏和确认的 Agent，本质上仍然是一套需要被照看的系统。

触发：如果我不能离开电脑，它真的算 Agent 吗？

最近在使用 AI Coding 工具时，我开始反复想到一个问题：我们现在使用的，真的已经是 Agent 了吗？

表面上看，我们已经可以把一个复杂任务交给 AI。它会读取代码、修改文件、运行测试，甚至生成提交和 PR。但实际使用时，我往往还是不能离开电脑：它完成一步，我检查一步；它理解偏了，我重新描述；它遇到障碍停下来，我再想办法把它推回正轨。

代码确实写得更快了，但人并没有真正从流程中离开。很多时候，我们只是从“亲自写代码”，变成了“全程照看一个写代码的 AI”。

如果一个 Agent 仍然需要不断被提醒、纠偏和确认，那么它更像一个需要实时指导的协作者，还不算真正落地。

观察：AI 编程正在经历三个阶段

我更愿意把软件开发中的 AI 分成三个阶段。

工具阶段：人发起每一次动作
最早的使用方式很直接：把一段代码贴进聊天框，让 AI 分析或补全，再把结果复制回项目。每一次交互都由人主动发起，AI 给出建议，人负责筛选和执行。这个阶段的 AI，本质上还是一个能力更强的搜索与辅助工具。
被照看的 Agent 阶段：AI 执行，人持续监督
到了第二阶段，我们开始把更完整的任务交出去。AI 可以自己搜索文件、修改代码、运行命令，但执行过程中仍然需要人高频介入。人虽然少写了一些代码，却承担了更多监督、纠偏和验收工作。
我认为，大多数团队目前仍然停留在这里。
自主运行阶段：人只在关键节点出现
真正值得期待的 Agent，不是把每一步操作做得更炫，而是能够在边界明确的情况下持续运行：理解目标、拆解任务、执行修改、验证结果，并在遇到高风险决策或无法判断的问题时再请求人工介入。
到这个阶段，人不再负责推动每一步，而是负责定义目标、设置边界和处理关键决策。

对比：瓶颈已经从写代码转向理解代码

过去，软件开发中最耗时间的环节之一是编码。工程师需要把大量精力放在实现细节上，代码产出速度自然限制了项目进度。

AI 改变了这件事。现在，代码可以生成得非常快，但人的阅读、判断和验证速度并没有同步增长。于是新的问题出现了：代码写得越快，等待人处理的内容就越多。

PR 会变大，一次修改涉及的文件会变多，Review 难度也会提高。更麻烦的是，当 AI 生成的代码持续超过一个人的理解能力时，项目表面上在加速，实际上可能只是在积累“理解债务”。

这种债务平时不一定明显。直到某天需要修改一个模块时，工程师才发现：这段代码虽然在自己的项目里，却像陌生人的代码一样难以理解。

所以，AI 提升的首先是代码生产速度，不一定是整个软件系统的交付效率。最终效率仍然取决于团队能否理解、验证并长期维护这些代码。

机制：真正稀缺的是人的判断带宽

Agent 可以参与越来越多的软件开发环节：整理用户反馈、探索解决方案、修改代码、运行测试、生成提交，甚至并行处理多个任务。

但这些能力没有消除人的工作，只是把人的工作推向了更上层：

客户真正需要解决什么问题？
这个需求应该如何拆分？
当前架构能否承受这次修改？
测试通过是否代表业务真的正确？
哪些错误可以回滚，哪些错误不能发生？
什么时候应该继续让 Agent 执行，什么时候必须停止？

这些问题的共同点是，它们都依赖对业务、系统和风险的理解。AI 可以协助分析，却很难替代最终责任。

换句话说，Agent 越能执行，人的判断力就越容易成为整个系统的新瓶颈。

推演：多 Agent 团队不会自动带来更高效率

目前更前沿的方向，是让多个 Agent 在后台并行工作。一个 Agent 处理前端，一个修改接口，一个补测试，还有一个负责检查代码。理论上，它们可以同时推进多个任务，不需要工程师全程盯着。

但并行本身不会自动产生效率。

如果多个任务依赖同一组文件、共享同一套数据结构，或者对同一个业务概念做出不同理解，最终就会出现大量冲突。Agent 生成了更多 PR，工程师却要花成倍时间理解差异、解决冲突和判断应该保留哪一种实现。

因此，多 Agent 协作最难的部分可能不在执行层，而在任务设计层。把任务交出去之前，工程师需要先判断：

哪些任务彼此独立，可以并行？
哪些任务存在依赖，必须按顺序执行？
哪些模块容易产生文件冲突？
每个 Agent 的输入、输出和验收标准是什么？
哪些决策可以自动完成，哪些必须留给人？

如果这些问题没有提前想清楚，多 Agent 只会把混乱并行化。

不同模型之间也会逐渐形成更明确的分工。有些模型擅长理解整体架构和制定计划，有些模型更适合执行具体修改，还有些模型在 Review、测试或查找边界问题上表现更好。未来有效的工作流，不一定是始终使用最强的模型，而是根据任务类型选择合适的模型，并让它们在清楚的边界内协作。

判断：Agent 的边界应该由风险决定

我目前更倾向于把人工介入点放在风险发生之前，而不是所有步骤之后。

低风险、可回滚、验收标准明确的任务，可以给 Agent 更大的自主空间。例如补充测试、调整样式、整理重复代码，通常可以让它完成后再统一检查。

涉及数据库迁移、权限、安全、支付、核心业务规则或不可逆操作的任务，则应该在关键节点暂停，让人确认方案和影响范围，再继续执行。

这个边界不会永远固定。随着模型能力、测试体系和工程工具逐渐成熟，人工介入点会不断向后移动。但无论 Agent 能力提升到什么程度，边界都不应该由“AI 看起来有多聪明”决定，而应该由错误成本、可验证性和可回滚性决定。

真正成熟的 Agent 工作流，不是完全没有人，而是让人只出现在最有价值的位置。

工程师的价值正在向上移动

在 AI Coding 时代，工程师的价值会越来越集中在定义问题、设计系统和做出判断上，而不只是完成具体实现。

这并不意味着编码能力不重要。相反，如果不能理解代码，就无法判断 AI 的输出是否可靠。变化在于，我们不仅要设计代码结构，还要设计任务结构、Agent 边界和验证机制。

工程师需要更强的系统设计能力，也需要更好的产品感：知道用户真正关心什么，知道怎样的结果才算完成，知道什么时候技术上可行却不值得做。

AI 并没有让“理解”变得不重要。它只是让执行变便宜，从而让理解、判断和责任变得更加稀缺。

本周旁注：低价 API 可能是另一种效率陷阱

最近我还花了不少时间寻找更便宜的 AI API 渠道。表面上是在降低使用成本，实际结果却是不断测试线路、切换配置、处理不稳定问题，让每天的工作流被反复打断。

后来我意识到，这和使用 Agent 时只关注代码生成速度是同一种误区：只优化了一个看得见的局部指标，却忽略了整个系统的真实产出。

便宜的 API 不一定便宜。如果为了省下一点调用费用，消耗了更多注意力和工作时间，它最终可能比稳定的中转服务或正规账号更贵。

对个人开发者来说，真正稀缺的通常不是 Token，而是连续、稳定、不被切断的专注时间。

开放问题

我现在还没有一个最终答案。

也许判断 Agent 是否真正落地，可以先问三个问题：

任务开始之后，人能否暂时离开？
Agent 遇到问题时，能否先自行验证和恢复？
人的介入是否集中在高风险、高价值的决策上？

如果答案仍然是否定的，那么我们拥有的可能还不是一个真正自主的 Agent，而是一套速度很快、能力很强，却依然需要被不断推动的系统。

接下来真正值得观察的，不只是模型还能写多少代码，而是我们能否建立一套与它的执行速度相匹配的任务设计、验证和责任机制。

当 Agent 真的可以独立工作时，工程师应该把自己放在系统的什么位置？

这个边界，可能才是未来几年软件开发最值得持续记录的变化。