随任务延续的上下文
参考其上下文与会话组织方式，为多步骤工作流保留输入、决策和工具反馈，减少每一步重新解释任务的成本。
Codex
参考 Codex 的开放 Agent Harness，为自己的工作流设计工具连接、任务状态与审阅边界。围绕 Floatboat 中的资料处理、任务执行和结果交付，判断哪些运行机制与集成方式值得复用。
关于 Codex
Codex 是 OpenAI 的编程 Agent 与开放 Agent Harness。公开项目提供模型周围的执行系统，让 Agent 理解工作区、维持对话、调用工具并逐步推进任务。这里的 harness 指运行与协作软件，不等同于模型权重。
对 Floatboat 用户而言，重点是判断自己的工作流在哪个环节需要更清晰的执行循环。Codex 为连接任务上下文、工具、反馈与人工审批提供了具体参考；可以评估软件组件的复用，也可以先将这些设计原则用于现有流程。
仓库采用 Apache-2.0 许可。OpenAI 模型、订阅和托管服务有独立的访问与商业条款。开放 harness 让实现可被查看和扩展，但不能据此承诺本地源码包含所有托管 Codex 功能。
值得借鉴的工作流机制
先理解项目展示了什么机制，再判断它能解决自己工作流中的哪个具体问题。
有边界的工具循环
研究工具结果如何影响下一步，再明确自己的流程哪些步骤可以继续执行、哪些节点需要人工审阅。
运行层集成选择
比较 CLI、SDK 与 app-server 的职责，判断现有工作流需要一次性任务，还是能够持续推进的 Agent 会话。
如何用于自己的工作流
将这些场景作为 Floatboat 中任务设计的参考；具体软件接入仍需单独核对兼容性与权限。
从研究资料到交付成果
借鉴上下文、工具与审阅的协作方式，设计从原始资料到已核对草稿的过程，明确证据和最终验收节点。
可重复的代码任务
将代码调查、实施、验证与审批分开，使重复性仓库任务在各阶段都有可审阅的结果。
自己的工作空间中的 Agent
当自己的应用或流程需要掌握业务上下文与可用操作时，评估官方集成入口是否适合。
从项目参考到工作流验证
从具体任务和可验证的小改动开始，判断需要优化说明、连接工具，还是复用运行组件。
- 01
定位一个流程瓶颈
先确定缺少的是上下文、工具、状态衔接还是审批节点，再判断是否需要运行层组件。
- 02
明确输入输出与边界
为该环节写明输入、允许使用的工具、预期输出，以及必须由人作出的决定。
- 03
验证一个小型完整循环
使用代表性输入测试完整过程，检查证据、修改与失败行为，再扩大工作流范围。
相关 Agent 项目
从不同的运行方式、扩展机制和工作流出发，比较其他独立 Agent 项目。
Codex 常见问题
Codex 是模型还是 Agent Harness？
Codex 的开源项目提供 Agent 与 harness 实现，负责组织上下文、工具和任务执行。它使用的模型属于系统的另一部分，不能把运行层开源理解为模型权重也在此仓库中。
CLI、SDK 和 app-server 有什么区别？
CLI 面向直接交互，SDK 用于程序化 Agent 工作流，app-server 则为需要持续对话、事件流和审批处理的应用提供会话协议。选择取决于使用场景，不必同时使用全部入口。
源码许可是否包含免费模型调用？
不包含。Apache-2.0 适用于项目源码；模型访问、订阅权益、API 调用和托管服务各自有独立条款，可能存在费用和使用限制。
Codex 能嵌入自己的应用界面吗？
可以。OpenAI 提供 app-server 与 SDK 集成说明，由应用提供界面和相关上下文，并明确 Agent 可使用哪些工具、哪些操作需要人工审阅。
开放 harness 是否包含全部托管功能？
不一定。公开运行层与集成入口不同于托管基础设施、账户功能和模型服务，具体功能是否属于源码范围，应查阅对应官方文档。
借鉴这些机制是否需要更换工作工具？
不需要。可以先将 Codex 作为任务结构、工具边界和结果审阅的设计参考，在已有工作流中验证思路。软件复用是另一项选择，需要核对兼容性、权限与许可；借鉴设计思路不会自动完成软件与 Floatboat 的连接。