同一项工作交给 AI，通常不会从“帮我整理一下”直接跳到“以后你自己完成”。
一开始，我们只让它生成一份草稿。结果稳定之后，会想把提示词固定下来，再让它自动读取资料。接着，又会想让它调用工具、修改文件，甚至定时运行。
AI 每多做一步，我们交出去的权限也会多一点。问题是：什么时候可以继续往前走，什么时候应该先停下来？
最近，OpenAI 发布了一篇文章，介绍 Basis、Clay 和 Exa 三家公司怎样把 Agent 放进真实工作流。三个案例做的事情完全不同，却刚好形成了一条清楚的递进路线：先固定一项稳定任务，再给它持续更新的上下文，最后才允许它把机会推进成经过测试的实际动作。
我根据这三个案例整理了一份检查表，方便大家对照自己的工作流，判断哪些环节可以交给 AI，哪些条件还需要补齐。
01 先把一项稳定任务固定下来
Basis 做的是新员工入职。
过去，新员工需要由 HR 带着完成一系列设置。后来，团队先完整演示了一遍流程，再把它做成一个公司内部的 Skill。新员工入职时，Codex 会介绍关键概念，并在后台完成相关工具的集成设置。
这项任务能被固定下来，靠的是几个基础条件：什么时候开始很明确，中间步骤相对稳定，需要哪些工具也很清楚，最后还有一个明确的完成状态。
团队依然留在流程里。遇到例外情况或复杂问题时，仍然由 HR 接手；重复出现的新问题，则会被补回 Skill，留给下一批员工使用。
所以，工作流的第一个成熟标志是可重复。
想把一项任务固定下来，至少先回答这五个问题：
什么情况会触发这项任务？ 每次需要完成的结果是否基本一致？ 中间步骤和所需工具是否已经清楚？ 什么状态才算完成？ 遇到哪些例外时必须交还给人？
如果这些问题还说不清，最适合的方式仍然是人带着 AI 一次次做。此时急着写 Skill、设定时任务，只会把一个尚未稳定的做法重复更多遍。
02 工作会持续变化，就给它一个固定的上下文空间
Clay 的客户工作很难靠一份固定流程解决。
一次交易的关键信息可能散落在 CRM、邮件、Slack、通话、演示文稿和内部讨论里，而且每天都在变化。如果 Agent 每次运行都从零开始，它即使知道该做哪些步骤，也不知道这个客户现在进展到了哪里。
Clay 的做法是为每个客户建立独立的持久工作区和专属 Agent。Agent 会定期查看一手资料，更新客户文件；另一个协调 Agent 再把所有账户的变化整理成当天值得优先处理的动作。
到了这一阶段，需要增加一套上下文维护方法：资料放在哪里、多久更新一次、建议依据什么证据，以及最后由谁决定是否采取行动。
官方文章特别提到，支持建议的一手证据会和建议放在一起，销售人员可以在行动前回看原始信息。Agent 负责收集、更新和整理，人仍然负责判断这一步是否值得做。
当任务会跨越多天、多个工具或多次对话时，可以检查下面几项：
重要背景是否保存在聊天之外，而不是每次重新口述？ 文件或工作区有没有固定结构，让下一次运行知道去哪里找？ 上下文多久更新一次，过期信息怎样被发现？ AI 给出的建议能否追溯到原始资料？ 不同人员和不同 Agent 能看到哪些内容，权限是否清楚？ 哪个节点仍然需要人作出决定？
这些问题没有解决时，AI 可以帮助整理当前资料，却不适合根据一段可能已经过期的上下文持续推进工作。
03 允许 AI 执行之前，先让结果可以被测试
Exa 的案例又向前走了一步。
团队希望发现更多适合接入 Exa 搜索 API 的开发者项目。这个过程原本需要持续观察代码仓库和外部生态，判断机会、收集背景，再协调开发和沟通。
现在，Codex 可以监控高优先级机会、收集相关信息、创建 Pull Request、运行测试并准备每周更新。必要时，它还可以起草下一步对外沟通内容，交给团队审核。
这里最关键的变化，是 Agent 的执行结果可以被看见和验证：代码改动落在 Pull Request 里，正确性先由测试检查，真正发布之前还有人工审核。
与此同时，团队仍然自己决定哪些机会值得投入、可以作出什么承诺，以及怎样处理外部关系。工作越接近真实执行，权限、证据和决策权就越需要提前写进流程。
所以，在允许 AI 修改系统、提交代码、发送消息或公开发布之前，还要检查：
AI 可以执行的动作有没有明确范围？ 它使用的是完成任务所需的最小权限吗？ 每次执行是否会留下可检查的文件、记录或变更？ 有没有测试、校验规则或其他客观证据判断结果是否正确？ 哪些动作之前必须停下来等待人工审核？ 执行失败后能否撤销、重试或交给人处理？
能生成结果，不等于结果适合直接生效。只有执行范围、测试方法和人工检查点同时存在，AI 才从“给出建议”走到了“受约束地执行”。
04 一张可以直接使用的自动化成熟度检查表
三个案例之后，OpenAI 还给出了六个扩展步骤：选择一条值得改造的完整流程，确定结果和指标，写清 Agent 的任务说明，为它安排明确的负责人和权限，把有效实验沉淀成可复用流程，再把已经验证过的做法带到下一项工作中。
为了方便实际使用，我把三个案例和这六个步骤合在一起，整理成下面四组问题。
1. 任务是否已经稳定？
是否会重复发生，而不是临时出现的一次性需求？ 触发条件、输入、步骤和输出是否清楚？ 是否有明确的完成标准？ 常见例外是否已经出现，并且知道怎样处理？
这一组还没满足，先让 AI 辅助完成单次任务。等人和 AI 一起跑过几次，再把稳定部分写成固定提示词、操作流程或 Skill。
2. 上下文能否持续维护？
重要背景是否保存在固定位置？ 是否有统一的文件结构和更新频率？ AI 能否区分最新信息、历史信息和未经确认的信息？ 建议能否回到原始证据？ 访问权限是否和人员职责一致？
任务已经稳定，但这一组还没满足，可以让 AI 按固定步骤处理当前资料，不要让它在缺少可靠上下文的情况下长期自行判断。
3. 执行结果能否被验证？
AI 的动作范围是否明确？ 是否只开放了必要权限？ 结果是否有测试、校验或审核标准？ 执行过程是否可观察、可追踪？ 失败后是否可以回退？ 高风险动作前是否保留人工确认？
前两组已经满足，但这一组还没有满足时，AI 可以监控、整理、排序和起草，也可以生成等待审核的文件；修改、发送、发布、付款等会产生实际影响的动作仍然留给人。
4. 这套流程能否持续改进？
是否有人对最终结果负责？ 是否记录了时间、质量、成本、异常率或审核负担等指标？ 人工发现的问题能否回到流程和规则里？ 权限、检查点和停止条件是否会根据实际结果调整？ 已经证明有效的部分能否被其他任务复用？
这一组决定的不是 AI 能不能完成某次任务，而是这套流程能不能长期运行。没有负责人和反馈机制，再完整的自动化也会慢慢偏离真实需求。
05 根据检查结果，决定放权到哪里
没必要为了显得“自动化”而把每项工作都推到最后一级。
如果任务本身还不稳定，就让 AI 参与探索和草拟；如果流程稳定但上下文容易变化，就先建立固定的资料空间；如果上下文已经可靠，但结果缺少测试，就让 AI 产出待审核成果；只有当范围、证据、测试、权限和人工接管都清楚以后，才适合开放受约束的执行。
比如，行业资料整理可以停在“自动收集并生成候选，人来选择”；旅行规划可以做到“持续比较并生成方案，人来预订”；代码修改则更适合在测试和代码审核都通过后，再进入后续环节。
一条工作流成熟到什么程度，取决于它能提供多少可靠依据，而不是 Agent 一次能跑多长时间。
06 写在最后
OpenAI 的结论是：工作流不断证明自己之后，Agent 承担的责任范围才会逐渐扩大。
这也是逐步放权最稳妥的顺序。先证明任务可以重复，再证明上下文可以持续维护，最后证明执行结果可以测试和审核。每增加一层能力，也补上一层证据和控制。
衡量 AI 自动化是否成熟，要看出了问题以后，我们能不能知道哪里错了、阻止结果继续生效，并把这次问题变成下一轮更可靠的规则。
相关文章
