假设你在本人通用会话中提出一项文件工作：核对一个项目目录里的说明文档与示例代码，列出不一致之处，形成修改建议。你可能希望这次使用 Codex 或 Claude Agent，也可能希望继续使用当前执行方式。选择的价值，是让合适的执行能力进入这项工作，而不必为一次工具变化另行组织全部交办。
《我们为什么做 Teloa》提出，模型和 Harness 可以演进，用户的团队积累应当能够延续。落实到这个例子，首先要保留原问题：核查什么、哪些差异值得报告，以及返回以后还要由谁判断。
Teloa 当前由 DeepSeek Harness（DSH）承接主会话，通过原生外部子执行接入 Codex 与 Claude Agent。原目标留在父会话，具体工作可以使用适合的执行路径，结果再回来参与同一项交付。
先分清要换的是模型，还是做事方式
| 选择 | 主要改变什么 | 在这项文档核查中想解决什么 |
|---|---|---|
| 更换模型 | 推理、表达、调用协议与用量 | 对同一份材料作不同分析，检查差异是否支持结论 |
| 更换执行引擎 | 工具、工作环境、等待和结果返回 | 采用另一套熟悉的代码与文件工具工作方式 |
是否值得切换，要看这次任务需要什么。把两种选择都放进一张模型列表，容易让工具与执行方式的差异被名称遮住。
将这两层分开，也让选择更准确。研究岗位换一个模型，不应该顺便改变它负责哪些客户、采用哪些资料；本人通用工作选择一次外部引擎，也不应该被理解为永久重建主会话。用户改变的是这次工作的执行安排，原问题仍然需要得到回答。
把核查交出去，把原问题留下
继续前面的假设。用户要求核查文档与示例的一致性，外部子工作可能返回差异清单、检查依据或尚未完成的部分。返回“执行成功”，本身并不能说明文档已经准确，也不能说明建议已经被采用。
父会话保留原目标，才有位置继续判断这些内容。某个示例可以运行，但它支持的参数与说明不同，仍然属于原核查问题；另一个文件没有取得，则需要保留缺项，不能由一份看起来完整的清单掩盖。
在当前路径中，外部子执行的状态与结果回到父会话。原交办、后续追问与结果整合因此可以留在同一项工作中，而不用让用户把一段脱离来路的结果再转述给另一位助手。
这种组织保留了选择的实际用途：用户可以利用不同引擎的工具与工作方式，又不必因为选择改变就放弃原来已经形成的要求。代价是 Teloa 要处理真实的生命周期差异，让开始、等待、返回和停止仍能对应这次工作，不能只把多个接口包装成相同按钮。
哪些工作目前可以交给外部引擎
共同入口不能使不同执行环境自动取得相同保障。当前岗位、业务和群中的工作有受管资料与工具范围，外部提供方尚不能完整继承这些条件，因此这类工作继续沿原受管路径。
外部子执行用于当前支持的本人通用会话及独立通用工作。使用时需要可人工审批的安全模式，以及本次独立执行许可；独立通用工作还要绑定原运行和当前授权。引擎是否加载、原指令和会话条件是否仍有效，都要在实际启动时核对。
这项许可尤其需要被准确理解：Teloa 的文件范围与逐项审批不会传入外部引擎，外部执行使用引擎自己的原生权限。 工作目录是本次执行需要明确的条件，不能据此声称已经建立了与 Teloa 相同的文件隔离。用户应依据实际许可内容判断是否交出这项文件工作。
引擎选择也以本人直接要求为依据。资料里提到 Codex，不等于要求使用它；本人明确指定了一个引擎，它不可用时也不能静默换成另一个。选择、可用性与执行许可必须在这一次工作上相遇，而不是由一个品牌名称代替。
选择以后，仍以原交付判断结果
回到文档核查。外部子工作返回以后，仍要检查差异是否有依据、哪些文件没有核查、修改建议是否解决原问题。用户决定采用哪项建议，后续要求也继续围绕这些具体内容提出。
这让开放选择有一个比“支持多少引擎”更实际的标准：采用另一种执行方式以后，人是否仍然知道交办了什么、收到了什么，以及接下来需要判断什么。某个引擎更适合这次工具工作，不会替它的输出免除核对；某次结果不合适，也不必因此丢掉原目标重新开始。
以后再检查同一个项目，工具和模型都可能变化。值得留下的是已经确定的核查要求、可追查的结果与尚未解决的差异。执行选择应当帮助用户继续处理这些问题，而不是每换一种工具，就重新建立一份工作来路。