OnionTalk

从执行瓶颈转向判断瓶颈

编码 Agent 可以生成代码、修复编译错误、补充测试或重构文件，因此一些过去需要人工逐步完成的工作会更快。但执行速度提升，并不代表一个人能够同时理解更多项目。每个并行任务仍需要有人阅读变化、判断方案是否符合需求、发现边界问题并决定下一步。

OnionTalk 的文章描述了一个容易出现的状态：一个 Agent 开发新功能，另一个处理缺陷，第三个探索临时想到的点子。终端里看起来都在工作，但当结果陆续返回时，使用者可能已经没有足够精力逐项检查。任务数量增加了，完成质量和收尾能力却没有同步增加。

这说明新的限制可能从“写代码需要多久”移动到“人能否清楚掌握正在发生什么”。当未完成事项太多时，注意力需要在代码、运行结果、决策记录和临时想法之间反复切换，重要信息容易被遗漏。工具扩大了可执行的工作量，却没有自动扩大人的判断和记忆能力。

什么是人的上下文容量

一次开发任务不仅包含源代码，还包括目标、约束、已作出的决定、测试状态和剩余问题。人在短时间内能够稳定把握的信息有限；任务切换越频繁，重新建立背景所需的时间越多。所谓人的上下文容量，可以理解为当前能够清楚追踪并用于决策的工作信息范围。

当同时运行多个 Agent 时，每个任务会产生自己的变化、日志、问题和待办。使用者需要记住哪个 Agent 改了什么、它依赖什么条件、是否触碰共享文件，以及哪些结果已确认。如果这些信息只留在不同会话中，切换时就要反复阅读历史并重新理解状态，增加认知负担。

文章所说的“Human Context Engineering”关注的正是如何管理这些人类侧的上下文。它不是简单增加更多 Agent，而是让任务、决策和验证过程保持可理解。记录清楚的目标与状态，限定同时处理的事项，并给自己留出审查时间，能够减少“所有事情都在进行，却没有事情真正结束”的情况。

控制并行任务数量

并行工作适合边界清楚、彼此独立且结果可以分别检查的任务。如果多个 Agent 同时修改同一模块、共享关键接口或依赖相同未确认假设，增加并行度可能造成冲突和整合成本。开始新任务前，可以先判断它是否会影响当前工作，以及自己是否有余力在结果返回时完成检查。

一种简单做法是为活跃任务设置上限。超过上限时，先收尾或暂停现有事项，再接受新想法。暂停不是丢弃任务：需要记录当前状态、已完成内容、遇到的问题和恢复条件。这样可以把注意力集中到有限的任务上，也减少多个会话同时等待人工决策的积压。

也可以按照任务风险安排并行程度。只读检索、独立文档整理或隔离测试相对容易并行；修改相同代码、执行数据库迁移或接触外部系统的工作则需要更谨慎的协调。每个任务都应明确文件范围、接口约束和交付标准，避免 Agent 之间互相覆盖成果。

为每个任务建立清楚的记录

任务记录不必复杂，但应能回答几个问题：目标是什么、为什么做、当前状态如何、哪些决定已经确认、下一步需要什么，以及哪些内容尚未验证。Agent 返回结果时，可以把摘要、改动位置、测试结果和限制写回同一任务记录。这样即便稍后恢复，也不需要完全依赖长对话历史。

若 Agent 使用工具或修改文件，应记录相应证据而不只记录“完成”。例如，说明修改了哪些文件、运行了哪些命令、哪些失败仍未解决。这样使用者可以更快决定是否接受结果，避免把模型自述当作已经验证的事实。对于需要多人协作的项目，统一格式也有助于他人理解当前状态。

把验证时间纳入工作计划

Agent 生成代码后，使用者仍需审阅行为是否符合目标。并行会话过多时，验证往往被推迟，因为新任务不断吸引注意力；但推迟越久，改动背景越难回忆，整合失败时成本也可能上升。因此任务估时不应只计算生成代码的时间，还要包含阅读差异、运行检查和处理反馈所需的时间。

可以为每个任务设置一个完成定义，例如需要通过哪些测试、哪些用户行为必须保留、哪些边界条件需要手动确认。收到结果后先判断它是否满足定义，再决定继续、返工或关闭任务。若无法理解 Agent 的修改，先缩小问题范围，要求解释关键决策或拆分改动，而不是将其直接合并。

把检查步骤写成清单也能降低上下文切换成本。代码审阅可以从需求覆盖、数据流、错误处理、权限边界和测试变化逐项检查。文档任务则可以确认事实来源、结构完整性和链接有效性。验证由人完成，但清晰的标准可以让注意力更集中。

管理新想法与待办

Agent 执行期间容易产生新的点子，尤其当等待某个任务时。若每个想法都立即启动新会话，工作集合会不断膨胀。可以把临时想法先记录到待办列表，附上产生原因、预期价值和重新评估时间，而不是立刻打断当前任务。

待办记录的作用是保存想法，不是承诺马上实施。之后可以在固定时间统一评估，删去已失去意义的事项，选择与当前目标一致的任务开始。对长期项目而言，保留清晰的“正在做”和“以后再做”边界，通常比不断增加并行会话更容易推进到真正完成。

让工具符合人的工作节奏

好的 Agent 工作流应该让进展可见，并在需要人工判断时及时停下。任务界面可以显示等待、运行、需要决策和已完成等状态；会话名称能够反映目标；变更摘要可以帮助快速回到上下文。系统还可以提醒活跃任务数量、未审查结果和长时间未更新的事项。

自动化程度提高后，人工注意力更应该用于目标选择、风险评估和结果判断。低风险重复步骤可以交给工具执行，但写入、删除、对外发布等有影响的操作仍需要清晰边界。控制并行不是阻止使用 Agent，而是让自己有能力理解和负责它们产生的结果。

从个人体会到工程习惯

OnionTalk 的文章以作者自己的工作体验为出发点，提出执行速度不再是唯一瓶颈。它没有把多 Agent 工作描述成只需增加工具就能解决的问题，而是强调人需要管理有限的上下文和判断能力。对于使用编码 Agent 的开发者，可以从减少同时进行的任务、记录每项状态、明确完成标准和安排审查时间开始。

博客还围绕 Shift Left、Harness Engineering 等主题持续讨论 AI 编码工具与软件工程。读者可以结合自身任务规模调整并行方式：当工作彼此独立且容易验证时提高效率；当上下文冲突或结果难以审查时主动减速并完成收尾。工具带来的生产能力，只有经过人的判断和验证，才会转化为可靠的软件成果。