开放工程中，人的工作是不断确定目标
判断人的介入是否必要，先区分目标尚未形成、信息尚未取得与已有约束在执行中丢失。上下文工程可以减少后两类负担，却不能替组织自动形成承诺。
在开放工程中，人经常不是替 Agent 补上最后一点智能，而是在决定什么值得做、允许承担什么后果，以及何时改变方向。
同样写代码，可能在做完全不同的工作
“AI 是否会替代程序员”把差异很大的任务压缩成一个职业标签。一个人可能在明确规范下实现算法，另一个人则在协调团队、理解客户例外、兼容旧系统，并判断下周上线是否值得承担风险。两人都写代码，但代码在各自工作中的位置不同。
前一种任务的实现与验证，可以在相对稳定的环境中完成。后一种任务的外部沟通，却随时可能改变目标。客户确认了新含义，合作方调整了接口，历史数据暴露了例外，原先正确的实现就需要重新判断。这些变化不是模型多想一会儿就能推导出的隐藏答案，往往来自尚未发生的决定。
因此，评价自动化潜力时，应先观察有多少环节需要持续确定目标，而不是直接估计某个职业有多少比例属于 coding。
为什么某些人类决策无法预先消除
假设结算系统要处理历史订单。工程上可以保留旧算法，也可以统一切到新算法，两种方案都能通过各自对应的测试。选择哪一种，涉及已经对客户作出的承诺、财务口径、迁移成本与维护负担。在组织作出选择之前，测试无法自行决定应当期待哪个结果。
模型可以整理信息、比较方案、揭示后果，甚至提出更好的折中。但决定是否获得授权、谁对后果负责，仍是工作流程的一部分。外部环境变化、利益不一致或后果难以撤回时，把问题写成指令，不等于将它变成了封闭任务。
这就是 Human-in-the-loop 长期存在的一种结构性原因。模型能力提升可以减少低层介入，却不能自动消除需要通过协作形成的目标、承诺与责任。
人—Agent—人，可以是有效分工，也可以是糟糕设计
承认人需要在回路中，不意味着每一步都应要求确认。频繁打断用户，让用户手动寻找所有文件、撰写完整背景，再逐条纠正执行细节，会把准备成本转嫁给人。系统即使完成任务，也未必减轻实际负担。
更合理的分工是：在已授权范围内，Agent 主动读取相关状态、整理候选方案、完成可逆操作，并在真正需要选择时呈现清晰选项。问题应包含背景、取舍与推荐依据，让人能够决定；进展汇报应展示完成了什么、依据是什么、哪里受阻，而不是滚动播放大量动作日志。
主动性也需要边界。周期性工作需要目的、停止条件和可观察成果，访问数据与对外执行仍应服从权限。让 Agent 主动准备决策，不等于让它自行扩展目标或取得新授权。
先区分决策缺口与上下文缺口
阅读 Anthropic 的上下文工程文章后，我认为前面的判断需要加上一个前提：不能把 Agent 当下需要人的帮助，直接当作这一步必然需要人的证据。反复提问有时暴露的是信息获取和状态维护做得不好，而不是工作本身无法自动化。
Anthropic 将上下文工程视为持续选择和维护推理所需信息的过程。文章讨论按需读取资料，以及用压缩、外部笔记和子 Agent 隔离探索细节来支持长任务；也指出检索耗时和压缩遗漏信息的代价。［1］ ↗ 这些是管理已有信息的方法，不能据此推导企业决策已经可以自动完成。
回到历史订单的例子：若客户适用的规则已经批准并存档，Agent 没找到记录，首先要检查检索入口与权限；若它读到规则却在后续步骤中遗忘，就要检查任务状态如何保留。只有当规则确实未定，或者当前例外超出已有授权时，才进入需要责任人裁决的环节。这三类失败都可能表现为一次人工提问，修复方法却不同。
把“需要更多 context”写成可检查的问题
以下是我据此提出的设计设想，并非已经完成的企业实践。一个订单迁移任务可以分别保存原始规则、当前执行状态和待决事项。规则需要来源与适用版本；执行状态记录已经处理的范围和验证结果；待决事项说明冲突在哪里、由谁决定。模型生成的摘要可以帮助定位信息，但不应自行覆盖原始规则。
例如，任务恢复后发现规则版本改变，系统应重新确认哪些已有结果受到影响，而不是把上一次摘要中的“已确认”继续当作有效授权。这里需要验证的不是摘要读起来是否完整，而是关键限制、未决问题和证据链接能否跨步骤保留下来。一个更长的提示词，并不能替代这条检查路径。
在自己的项目中，我更适合先做小规模对照：固定任务和模型，分别提供完整历史、筛选后的材料以及带来源的任务状态，再记录完成情况、错误沿用旧信息的次数、人工补充次数、耗时与调用成本。只有确认减少了重复补充、同时没有增加漏掉约束的错误，才能说上下文设计减轻了人的负担。这是待开展的验证，不是现有实验结论。
企业自治程度，受制于组织状态
很多企业流程看似明确，实际运行却依赖隐含信息：客户适用特殊条款，某份表格已经失效，某类例外必须由特定负责人批准。事实如果只存在于人的记忆里，Agent 就会反复回到沟通。延长上下文，不一定能解决事实缺失与权威来源不明。
将业务对象、版本、权限、来源和状态迁移规则结构化，能够减少不必要的介入。系统知道哪份记录有效、哪些动作已执行、失败后从哪里恢复，工作才有机会连续推进。这是 structured state 的实际价值：使已经形成的组织决定可以被可靠执行。
但结构化不能替组织提前决定所有例外。遇到超出政策的情况，系统应把事实和后果提交给人，再将新决定写回状态。可以压缩的是搜集材料与重复解释的成本，需要保留的是形成政策和承担责任的环节。
为什么增加 Agent，未必增加团队吞吐
一个人能监督多少 Agent，取决于每个任务消耗多少不可并行的注意力。独立且验收清晰的任务可以并行；同时等待需求裁决、接口协调和人工 review 的任务，则会竞争同一份判断能力。执行者增加以后，工作可能堆积在人的决策队列。
这说明多角色系统在开放软件工程中仍需要检验整合成本。工作目录可以隔离，角色上下文可以分开，但需求冲突与系统整合不会消失。若要提高吞吐，应先减少耦合、澄清接口、自动化可执行验收，而不是增加“产品经理”“架构师”或“审查员”等角色名称。
评价工具时，我更关心每次交付占用了多少人的有效注意力，以及这些注意力是否用于重要选择。也应区分子 Agent 用来隔离资料探索，还是用来并行修改同一个系统：前者可能减少主流程的信息负担，后者还要处理接口冲突和集成验证。不能用一个研究任务中的收益，直接证明整个软件团队会获得同样的加速。
任务可自动化，不等于职业结论已经确定
编译器、操作系统、形式化方法与仿真工作，包含许多可以在本地反复执行的子任务。但生产环境中的硬件差异、客户负载与部署约束，也可能将它们重新带回开放系统。业务开发中的迁移、重构与回归修复，如果边界充分明确，同样可以获得较高自治程度。
“需要人参与”不应成为永久的职业保护证明，“可以自主运行”也不直接等于岗位会消失。更低的成本可能压缩某类劳动，也可能使原本不值得做的需求变得可行。组织会减少人员还是扩大探索，不能仅凭技术演示推导。
对个人而言，我更愿意把重点放在理解需求、建立验证、整合系统与有依据的取舍上。不是为了人为保留必须经过人的步骤，而是因为这些工作决定了自动化究竟在为谁解决什么问题。