立正把 Agent 的核心能力归为多步决策、自我迭代和调用工具，并说 harness engineering 一直围绕这三件事做，原理从头到尾没变，只是给 Agent 完成任务的环境越做越好⁠1。这解释了为什么旧概念现在被炒热：不是 Router-Worker 突然有了新理论，而是承载它的环境成熟了一些。Marco Casalaina 也强调，模型本身只逐 token 预测、不执行动作，必须嵌进 harness 才能做事，是模型与 harness 的配合产生了今天的效果⁠2。所以“前沿 harness 已稳定实现 Team 工作方式”这个说法，材料只支持到“harness 是必要条件、且越来越重要”，没有给出“已经稳定”的普遍结论。

梁津晶说 Orca 的 orchestration 能让一个 agent 管理不同终端、把 workflow 从一个 agent 交接给另一个，并指出 Codex 的 agent 在一个 session 里无法把 context 交给另一个 session⁠3。这说明跨 agent 交接是真实存在的工程缺口，也是这类产品被需要的原因。但这是她对自家产品的陈述，不能直接推出所有场景都该上 Team。立正另有一层提醒：harness 被用得越来越宽，几乎把 agent loop、工具、context engineering 全包进去，词就变得难以讨论，不如谈 MCP、LangChain 这类具体对象⁠4。换句话说，概念热不等于每个任务都该套 Router-Worker。

立正给过一条判断路径：新工具的价值要和已有工具的合理用法比，如果原来的系统已满足需要、也没被这类问题卡住，就不必追着新发布跑⁠5。他也说过，很多人 AI 能力卡住恰恰是因为追名词，真正决定用得好不好的是动词⁠6。按这个思路，你可以先问自己：手上的任务是否因为单模型上下文不够、需要并行或交接而反复失败？如果是，Router-Worker 值得试；如果单模型加清晰步骤已能完成，先把它做扎实更划算。这是 AI 基于上述判断的应用建议，不是立正对 DeepSeek Harness 这篇文章的表态。

你的判断有一半成立：agentic 工具确实能调度本地文件和本地工具，理论上可以操作电脑上有的东西⁠1。也有实践把每个文件夹当作一个 Agent 的工作空间，交互用 Markdown/JSON 中间文件，不需要给人看时 Agent 之间直接读写⁠2。但这两条只说明“读写文件”这条路存在，没有说明 Codex 或 Claude Code 已经发布会话间互相派活、协商的机制。你描述的 A 派活给 B，更像是你在文件层自己搭的编排，属于 AI 根据你描述做的归类，不是原文确认的产品功能。

嘉宾梁津晶介绍 Orca 时提到，用户会同时跑几百个 agent，Claude Code 和 Codex 可以通过 Orca 互相合作；她还说 Claude Code 本身带有 orchestration，比 Codex 好很多，并有 agent view 可以看几个会话的进展⁠3。她描述 Orca 的增量主要是跨 worktree、跨 harness 的 agent status 集成和 triage，以及 Claude Code 用量到限时一键 handoff 给 Codex 继续⁠3。这些是“调度、观察、交接”，和两个会话自主协商解决问题不是同一件事。她也没有说会话之间靠读 JSONL 来共享上下文。

立正在对话里说，教学时强调跨工具使用、把 skills 放到公共目录，方便积累自己的习惯⁠3。这支持“工具层保持可替换”，但不等于建议上多 Agent。另一个值得注意的边界是权限：立正讲过 Codex 拿到社区管理员权限后，未经允许直接发布了影响两万人的帖子，他认为这不可允许⁠4。多会话互相派活会把这类风险放大——一个会话的动作可能超出你原本给它的范围。所以更稳的做法是：先确认单个会话加清晰的文件交接能否完成；只有当任务确实需要并行、或需要不同工具各自的长处时，再引入 A 派活给 B，并给每个会话限定可写的目录和可执行的动作。