今年暑假在阿里实习时，我反复思考的一个问题是：Agent 已经能写代码了，为什么我们还是不敢把任务交给它，然后离开电脑？
我们当时内部在开发的一套系统叫 Harness，目标就是让研发任务可以被异步托付：人给出需求，系统组织 Agent 完成开发、验证和评审，在需要人判断的时候再把人叫回来。这个目标听起来很直白，但真正要实现，光靠模型会写代码远远不够。
坐在电脑前使用 Coding Agent，这个差距不一定明显。需求说得不清楚，可以随时补充；它理解错了，可以立刻纠正；测试失败了，可以帮它判断是代码问题还是环境问题。整个过程看起来是 Agent 在持续工作，但人其实承担了不少没有被显式设计出来的职责：解释需求、判断进度、处理异常，以及决定什么时候算完成。
一旦希望把任务留到夜里执行，或者同时交出去十几个问题，这些职责就不能继续依赖“旁边刚好坐着一个人”。Agent 可能已经具备解决问题的能力，但系统还没有具备承接这项工作的能力。
我想讨论的，就是这段距离：任务怎么推进，失败以后怎么办，什么时候需要人，以及最终凭什么接受结果。还有一个在后来技术交流中变得更加具体的问题：我们究竟应该给 Agent 多大的自由？
Agent 越自由，真的越好用吗？
在一次和蚂蚁集团相关团队的技术交流里，我们接触到了另一种做法。对方使用的是一套基于 Multica 深度改造的系统，Agent 不必只沿着预先设定的阶段执行，也可以自己组织活动、拆解问题和编排任务。同时，我个人也是 Multica 的深度用户，几乎把 Multica 工作区当成了我的一个个人秘书。和我们的 Harness 相比，那套系统把更多决定“接下来做什么”的权力交给了 Agent。
这种自由在开放任务里很有价值。以产品工作为例，一个产品经理给出的可能只是“帮我看看这个功能接下来该怎么改”。这时，任务本身还没有定义清楚：应该先分析用户反馈，还是看使用数据？是否需要研究竞品，或者先做一个原型？这些事情很难在开始之前全部确定，甚至要查到一半，才会发现真正值得解决的问题。对于这类工作，让 Agent 自己组织任务，比强行套入一条预先规定的研发流程更合适。开放任务里，弄清楚该做什么，本来就是工作的一部分。
但代码交付不完全一样。一个边界清楚的缺陷修复，具体实现可能很难，定位过程也可能充满不确定性，但它要遵守的交付规则往往已经存在：修改要落在指定范围内，必要的测试必须执行，验证不通过就不能算完成，规定的评审也不能跳过。我们需要 Agent 自主判断怎么修，而不是每次都重新决定要不要验证、要不要评审。
这也是我更认可 Graph 优先架构来承接这类研发任务的原因。实现路径可以探索，交付规则不应该临场发挥。我们把阶段边界和流转条件提前放进系统，Agent 可以在节点内部充分发挥，但不需要额外承担重新组织整套交付流程的责任。
交流中，对方也提到，他们已经把那套系统用于一些服务端 Ops，也就是运维工作。这让我更具体地看到了自由编排的另一面：同样的架构，一旦进入需要控制实际操作范围的场景，就必须再补上明确的约束和任务边界。
拿一个典型运维场景来说，在授权范围内读取日志、分析指标、寻找异常原因，可以保留较大的探索空间；但到了修改配置、重启服务或执行变更的时候，哪些环境允许操作，哪些动作必须审批，一次任务最多影响多大范围，失败后是否允许继续尝试，都需要清楚的规则。“看看为什么变慢了”不能自动变成“可以调整所有相关服务”。这些是任务授权的问题，不能只依靠 Agent 对目标的理解来决定。
如果底层以自由编排为中心，要承接这样的工作，就需要围绕它额外建立任务范围校验、操作权限、审批和终止条件。这里说的约束，不只是多写几句 Prompt，也可以是工具权限和服务端强制检查；但无论放在哪里，这部分工程工作都不会因为 Agent 更自主而消失。对于本来就有成熟交付流程的任务，这相当于先给了 Agent 很大的组织自由，再把那些不能自由决定的部分逐项约束回来。相比之下，我们的 Graph 路线从一开始就把阶段、验收、回退和人工确认当成基本结构，承接这些要求更直接。
当然，图本身也不是安全保证。审批是否通过、操作是否越界，仍然需要由系统和工具执行层真正检查，不能只在流程图上画一个节点就算完成。Graph 的优势不是省掉约束，而是让一部分关键约束直接成为可执行流程的一部分。
严格说，这里比较的也不是“用图还是不用图”——动态编排同样可以表示成图。真正的区别是，哪些流程由系统事先规定，哪些允许 Agent 在执行中决定。那次交流让我更清楚地看到两条路线的适用范围：对于产品探索这类问题尚未定义清楚的工作，自主编排更有发挥空间；对于边界明确、需要稳定验收的代码交付，我更倾向于我们这种 Graph 优先的设计。自由度不是越多越好，要看它被用来解决问题，还是让系统不得不重新约束那些本来就不该改变的规则。
让人离场，但给人留下判断的位置
这套思路不意味着所有任务都应该被塞进固定工作流。“看看这个产品还有什么机会”和“修复一个已经描述清楚的缺陷”，需要的自主性并不一样。前者需要探索问题、调整方向，后者需要在明确的范围和交付要求下完成工作。把所有任务都做成固定流程，会限制前者；把所有任务都交给 Agent 自由编排，又会给后者增加本来没有必要的约束成本。
我更感兴趣的一种组合，是让自主编排负责前期探索，在目标、范围和验收标准明确之后，再把任务交给固定研发流程。运维场景也可以作类似区分：授权范围内的诊断和分析保留探索空间，涉及实际变更的部分进入明确的审批、执行和验证流程。不是一定要选一个架构覆盖所有工作，而是把自由度分配给适合它的阶段。
所以，我更愿意用“有多少工作可以不再逐步盯着，却仍然得到可验收的结果”来判断一套 Agent 系统的价值，而不是看它一次能运行多久，或者同时能启动多少个 Agent。
模型能力当然仍然重要。这里讨论的工程结构，解决的是如何接住这种能力：让任务在正常情况下继续推进，在异常时留下记录，在需要判断时找到合适的人，在交付时提供足够的依据。
人能够离开执行现场，是因为系统接住了原本需要人一直盯着的部分，而不是因为我们决定不再检查。这也是我理解的从 Loop Engineering 到 Graph Engineering：保留 Agent 解决问题的自主性，同时认真设计一项工作怎样开始、怎样暂停，以及怎样才算完成。