EvoX 这类自进化 Agent 的能力边界，不是靠一次配置定死的。把任务描述交给它之后，它会自行决定读哪些文件、跑哪些命令、要不要再拆出子步骤。上手时要判断的其实是一件事：哪些步骤的输出，你能在执行记录里事后逐条对账。能对账、失败能重跑、副作用限制在有限范围内的步骤，通常可以先放手；涉及不可逆写入、对外发布或结论口径的节点，建议留在人工确认之后。

第一次用 EvoX，建议按“可核对、可回退、副作用可控”三条来划范围：只读检索、批量归类、草稿生成这类步骤可以先交给它跑；写库、改配置、对外发送、给出最终结论这类步骤保留人工确认；需要现场信息或口径判断的部分只能人工做。判断依据落在执行记录能不能逐条对照，而不是它跑得快不快。范围外和来源不明的步骤，按中断条件停下来处理。

把手上任务按能不能拆开分成三档

划档只看三条：结果能不能事后逐条核对、失败能不能重跑或回退、副作用是不是限制在有限范围内。三条都满足，才考虑放进第一档。

• 可完全交给 Agent：产出以文本或文件形式留下，每条结论都能回到原始输入对账；失败直接重跑，不触碰线上资源。我这边常放进去的例子，是把一次构建的日志按错误码归类，只读日志目录、把结果写成新文件。
• 需要中途确认：任务里有分叉选择或写入动作，前半段可以先跑，后半段要人看一眼。比如让 EvoX 改一份项目配置以启用某个开关，做法是先让它改分支上的副本并给出 diff，人确认 diff 之后再合并。
• 只能人工做：需要现场信息、口径判断，或者操作不可逆。比如判断某条失败用例算不算阻断发版，以及向外部系统发布成品。EvoX 可以生成步骤清单，但不建议让它直接执行。

分档不是按任务大小，而是按返工成本。同样一句“整理日志”，只读汇总和一键清理旧日志，应该落在不同档里。

为选中的任务写清输入、停止条件和验收口径

任务描述里缺哪一项，跑偏时就无法判断对错。建议用下面这段骨架，把方括号里的内容换成自己项目的真实路径和字段，再交给 EvoX。骨架本身可以直接存成模板文件，改路径即可复用。

目标：[一句话，说明产出什么文件或什么结论]
可用输入：
  只读目录：[路径]，不要读取 [需要排除的路径]
  可执行脚本：[路径]，只允许执行，不允许修改
完成判定：
  - 产出文件包含字段：[字段1、字段2、原始出处行号]
  - 每条记录都能在 [只读目录] 中找到对应原始行
中断条件：
  - 需要写入 [只读目录] 之外的路径时停下
  - 需要执行清单之外的命令时停下
  - 出现无法定位来源的记录时停下，并把这些记录列出来
收尾要求：列出读过的文件、执行过的命令

“收尾要求”这一行是给自己留对账入口的：执行记录里没有文件清单和命令清单，事后只能靠猜。完成判定要写成可检查的字段，不要写“整理清楚”“尽量完整”。中断条件写三类就够用：越界写入、越界执行、来源不明。

跑一次最小任务并逐步对照执行记录

第一次跑，选输入小、耗时短、失败可重跑的任务。跑完把执行记录和预期步骤并排抄成一张表，多出来的和缺失的分开标。下面是这张对照表的填法。

对照的目的是分清两类偏差：一类是 EvoX 自己补的步骤，可能有用但会扩大操作范围；一类是漏掉的步骤，通常说明验收口径写得不具体。两类都要落回任务描述里改，而不是靠下一次口头提醒。执行记录里看不到的命令，一律按没发生过来处理。

把人工确认点写进自己的操作清单

把确认点固定成清单之后，介入节奏可重复，不用每次重新判断要不要看。

1. 范围确认。触发条件：执行记录里出现任务描述未列出的目录、接口或命令。检查动作：逐条对照“可用输入”，不在清单内的先停下来，判断是扩范围还是拒绝。
2. 写入前确认。触发条件：EvoX 准备写文件、改配置或提交变更。检查动作：看目标路径和 diff，确认写的是副本或新文件，不是原始数据。
3. 命令执行确认。触发条件：出现带删除、覆盖、批量移动语义的命令。检查动作：读完整命令和参数，确认有备份，或者可以先在小目录上试跑。
4. 结论确认。触发条件：输出里出现“全部通过”“已修复”这类判定性表述。检查动作：抽查若干条记录回到原始输入对行号，把判定改成带出处的描述。
5. 收尾确认。触发条件：任务结束并输出收尾清单。检查动作：核对读过的文件与执行过的命令是否都在给定范围内，把多出来的步骤记进下一轮的中断条件。

这五条不必每次都走一遍。只读汇总类任务通常只需要范围确认和收尾确认；一旦出现写操作，写入前确认和命令执行确认就不能省。需要结合自己环境再调整的，多半是中断条件的粒度，而不是确认点本身。