我最近在想一个很容易被“已经能运行”掩盖的问题：一个本地执行器，究竟什么时候才算真的可以派活？
这次的场景很具体。我希望给它一句自然语言指令，再补上验收标准，让它自己拆步骤、执行任务，最后把真实产物交回来。任务可以是下载资料、熟悉一个项目，也可以是反复做同一种整理工作。表面上看，这只是把人的指令转给另一个程序；真正做起来，却马上碰到3个问题：我怎么知道它到底会什么，派出去的任务以后怎么找回来，最后拿到的到底是结果还是一条“已经完成”的提示？
这件事让我重新意识到，本地执行器从“能运行”到“可派活”，中间缺的不是一个更大的按钮，而是一条完整的责任链。能力要能被发现，任务要有身份，结果要能验收。少了其中任何一环，自动化都可能只是在制造一种很像完成的假象。
能运行，不等于知道它能做什么
最初看执行器时，人的直觉通常是先问：它现在能不能启动？进程有没有起来？界面里有没有出现一个任务？这些检查当然有用，但它们只回答了“入口还活着”，没有回答“这个入口能不能处理我手里的事”。
当一个能力藏在某个内部工具、某段经验或某个熟悉的人脑中，外部派活者就只能靠记忆猜。有人记得它能做下载，有人只知道它能整理文件；同一个动作换一种说法，能力边界就重新变成盲盒。这样做的后果是，派发前需要反复询问，派发后又可能发现路径选错，最后只能把本来应该自动执行的工作重新拿回手里。
一个执行器是否可派，第一关不是它有没有入口，而是不了解内部细节的人能不能查到它的能力和调用方式。
所以我更愿意先做能力自暴露。执行器应该把自己能处理的任务、所需输入、会产生的输出，以及真正的调用正门登记出来。外部只需要问“能不能做这件事”，就能得到一个可判断的答案，而不是翻遍工具说明，凭关键词拼出一条可能有效的流程。
这里的“自暴露”不是把所有内部实现摊开。对外真正有用的是能力契约：它接受什么，负责什么，不负责什么，成功时交付什么，失败时如何说明。能力目录的意义，也不是让人欣赏一张完整清单，而是让派活前的判断变得可重复。
任务不能只靠当下的窗口记住
第二个问题出现在派发之后。一个任务开始运行时，往往会产生一个后台会话、一个工作记录，或者一个执行实例。很多人因此担心：既然任务被交给后台了，过一会儿是不是就联系不上？
我一开始也把注意力放在“怎么找回那个会话”上。后来发现，真正应该解决的不是把所有会话都列出来，而是让每一次派发都带着一个稳定的任务身份。这个身份在创建时写入任务上下文，并一路跟随执行、回收和验收。这样，后面要找的不是一堆不知所云的会话，而是某一项明确工作留下的记录。
任务身份的价值，不是让人管理更多会话，而是让一项工作在离开当前页面后仍然能被准确指认。
如果不处理这个问题，执行器可能确实还在工作，但人已经无法判断它属于哪次派发，也不知道哪个结果对应哪个要求。任务越多，靠时间顺序、窗口位置和临时记忆猜测的风险越大。一次误认，可能把旧产物交给新任务，也可能为了“找回”而重复派发，造成重复下载、重复修改或重复发布。
我选择在派发规则里固化任务身份，是因为这比事后补一套查询界面更可靠。派发者最清楚任务的语义，也最早知道它要服务哪个目标。身份在起点生成并写入上下文，后面的执行器、回收器和验收器就不必再靠猜测建立关联。人仍然可以查看任务状态，但不需要把所有后台对象当成自己的管理清单。
真正的完成发生在产物回来之后
第三个问题最容易被忽略。任务提交成功，后台进程存在，状态栏显示“运行中”或“已完成”，这些都只能说明过程发生过，不能证明结果已经交付。
比如，我派出一个任务，让执行器完成资料整理并回收一个可使用的文件。它可能成功启动，也可能认真执行了若干步骤，但如果最后没有真实文件回来，我仍然无法使用这项工作。过程状态再完整，也不能替代产物本身。如果不处理，最危险的后果不是任务偶尔失败，而是系统把没有结果的任务包装成成功，逼着人继续相信错误状态。
因此，回收阶段必须从“读状态”切换成“验收物”。先检查约定的真实文件是否存在，再核对它是否属于这次任务，最后验证内容摘要、格式或其他验收条件。检查不通过就报红，明确说明是没有产物、产物不匹配，还是产物不满足标准。
没有真实产物，就不能把任务标记为完成；模糊状态只能作为过程信息，不能作为交付凭证。
这条规则看起来有些严格，却是本地自动化最基本的诚实。执行器可以在中途失败，可以遇到权限或环境问题，也可以暂时没有办法完成；这些都比“假成功”容易处理。失败至少会留下下一步判断，假成功则会让人把错误继续传给后面的流程。
最容易误判的3个信号
这次梳理下来，我觉得有3个错误捷径特别常见。
第一个是把“任务提交成功”当成“任务执行成功”。提交只是入口接受了请求，后面是否真正执行、是否完成、是否产出，还没有答案。第二个是把“后台有进程”当成“任务没有丢失”。进程存在只代表某个东西在运行，不代表它与当前目标建立了可回溯关系。第三个是把“状态接口返回完成”当成“用户拿到了结果”。完成状态可能只覆盖内部步骤，未必覆盖真实文件回收和验收。
我没有选择用更多状态词来遮住这些缺口，是因为状态越多，误读的空间反而可能越大。更稳妥的做法是把过程状态和交付状态分开：过程状态回答“现在走到哪里”，交付状态回答“我能不能把这个结果交给人”。只有后者通过，整个任务才算完成。
这里也有一个边界：并不是每项工作都一定产生文件。文字回复、结构化数据或其他结果同样可以是产物。但无论形式是什么，都必须有一个可读取、可关联、可验收的真实对象。不能因为结果不是文件，就退回到“系统说完成了”的模糊判断。
把3件事串成一条可复用流程
我现在会把方法拆成3个阶段。第一阶段是登记能力：把输入、输出、边界和正门写进可发现的能力目录，让派活者先确认“这件事是否真的能做”。第二阶段是派发任务：生成稳定任务ID，把它写入执行上下文和预期产物约束中，让后续每个环节都能沿着同一身份回溯。第三阶段是回收验收：找到真实产物，核对归属和内容，再根据验收标准决定通过或报红。
这不是为了增加流程感，而是为了把原本藏在临场记忆里的判断变成系统约束。能力目录解决“能不能做”，任务身份解决“是哪一次”，产物验收解决“到底做没做成”。这3个问题分别位于派发前、执行中和交付后，不能用其中一个阶段的顺利，替代另外两个阶段的证据。
方法还需要保留失败路径。能力查不到时，应当报告能力未暴露，而不是自行拼凑调用方式；任务找不到关联时，应当报告身份缺失，而不是从全部会话里猜一个最像的；真实产物回收不到时，应当报红，而不是根据后台日志推断“应该已经完成”。
可靠的自动化不是让每一步都显得顺利，而是让每一个关键判断都有对应证据。
这件事让我重新意识到，执行器真正替人省下的，不只是点击和等待的时间，还有那些重复确认“你到底做了吗”的时间。前提是系统愿意把能力、身份和结果都留下来。否则，人只是从亲自做事，变成亲自检查一段含糊的状态描述。
下次我会怎么做
下次再接入一个本地执行器，我会先问3个问题：外部能否查到它适合做什么，派发后能否凭任务身份找回这一次工作，结束时能否拿到并验收真实产物。任何一个问题答不上来，我都不会把它包装成“已经可派活”。
我会先用一个无害的小任务走完整链路，而不是一开始就交付重要工作。确认能力目录能给出正门，确认任务身份能贯穿执行记录，再确认回收端确实拿到了可用结果。过程中如果没有产物，就让系统报红；如果只是状态看起来正常，也继续等待交付证据。
我更愿意把这看成一种工作习惯，而不是一个技巧。真正成熟的执行器，不是让人忘记它在后台运行，而是让人随时知道它为什么被派出、现在属于哪项工作、最后交回了什么。下次我会把“可发现、可回溯、可验收”作为本地执行器进入工作流的最低门槛。