区分界面与执行
研究工作台的层次，明确流程中哪些部分负责收集背景，哪些负责执行任务。
ZCode
参考 ZCode 的工作台与 Agent 运行时设计，优化自己工作流中的任务背景、执行反馈和人工审阅。结合公开源码与不同交互入口，评估适合 Floatboat 工作方式的组织机制。
让图示任务与工作空间保持关联
说明一项需要连接资料、进展和审阅决定的长任务，以 ZCode 为参考区分界面与执行职责。请求先形成范围明确、结果易于判断的设计，再考虑扩展工具或增加其他界面。
带入 Floatboat 的请求
请求可预览和复制，不会从此处自动发送。
参考来源: ZCode https://github.com/zai-org/ZCode 先阅读原始说明并核对当前环境与依赖。需要安装或连接新工具时，先提出方案。 我的任务: 研究 ZCode 的 UI Plugin 文档和 Excalidraw 示例，为项目笔记设计可编辑流程图工作流，保留修改与来源笔记的关联并导出可审阅结果。核对 API 后再提出集成方案。 期望交付: 包含数据边界的插件交互草图，以及小规模兼容性测试。
关于 ZCode
ZCode 是 Z.ai 的编程 Agent Harness 与开发工作台。官方仓库介绍桌面、浏览器和终端体验，包含客户端、后端服务、共享 UI、Agent CLI 与运行时源码，范围大于单个编辑器插件或任务指令。
它作为工作流参考的价值，在于界面、后端服务与 Agent 执行之间的关系。Floatboat 用户可以据此思考上下文从哪里进入、任务过程如何呈现，以及何时需要人工审阅操作；实际复用仍需单独验证集成方式。
公开源码采用 Apache-2.0，仓库另有项目声明说明运行和第三方事项。源码公开不能代替模型访问、托管服务条款或应用行为的具体判断，应结合所选版本阅读官方声明和发行说明。
值得借鉴的工作流机制
可见进度需要与项目资料和实际执行对应，才足以支持审阅。ZCode 对界面和运行职责的划分提供系统参考；状态正在变化，并不等于交付结果已经达到要求。
让任务过程可审阅
参考应用组织方式，将 Agent 活动与用户作出判断所需的上下文一起呈现。
研究完整系统关系
评估流程模式时结合客户端、后端、CLI 与运行层理解，避免只复制孤立界面。
ZCode的使用场景
长任务需要让资料、当前活动和结果始终关联，人工批准又依赖清楚的审阅材料。ZCode 可供研究这些连接及多界面职责，使用户知道正在接受什么，而不只看到执行日志。
以任务为中心的工作区
较长任务中，原始资料、工作目录和目标交付物需要始终保持关联。说明当前活动如何使用这些输入，以及推进过程中怎样保留任务状态。工作空间设计应能够从最终结果追溯到产生它的操作，而不是只展示当前正在发生的动作。
人工审阅节点
审阅 Agent 提出的修改或外部操作时，使用者需要的不只是执行日志。应明确相关上下文、拟议变更及支持接受它的证据，并将这些材料组织到审阅节点中。批准行为建立在能够理解的结果上，而不是一串难以判断含义的运行记录。
跨入口的工作流
同一任务同时出现在桌面、网页或终端时，需要明确状态由哪一层维护、执行由哪一层负责。梳理不同入口共享的任务信息和各自职责，并核对它们的一致性，避免多个界面逐渐维护出互相冲突的工作版本。
梳理任务信息的处理位置
桌面界面展示的工作，可能涉及另一个服务边界中的数据或执行。参考 ZCode 项目说明和源码，区分哪些在本地、哪些在远端，以及各部分背景由哪个组件接收。将这张路径图用于自己的工作空间设计，再决定资料范围和批准怎样伴随执行过程。
核对 ZCode 数据边界
本地与远程执行可能将任务信息交给不同接收方。以下条件结合 ZCode 源码和项目说明确认这些边界，再提供材料；实际服务路径需要单独核对，不能只根据桌面界面判断。
检查数据与执行边界
结合项目声明与源码评估本地、远程以及接收任务资料的服务边界。
用 ZCode 验证一条审阅流程
同一任务跨越界面和工具时，上下文与执行职责需要保持清楚。先验证一个完整、可审阅的结果，再判断哪里值得增加入口或能力，避免扩展过程把任务状态拆散。
梳理任务层次
区分业务背景、用户交互、执行工具和需要审阅的结果。
验证审阅循环
先验证一个任务从输入到可审阅结果的完整过程，再扩展工具与交互入口。
相关软件项目
比较这些项目的用途、运行条件和源码许可。
ZCode 常见问题
ZCode 是否包含 Agent Harness？
包含。官方将 ZCode 定位为编程 Agent Harness，仓库除应用代码外也包含 Agent CLI 与运行时，并非仅用于展示模型接口的界面。
ZCode 只有桌面应用吗？
不是。仓库介绍桌面、浏览器和终端入口。应分别核对所选入口的要求，不能假设一种入口的配置可以原样应用到另一种。
ZCode 官方仓库属于谁？
官方仓库为 Z.ai 组织下的 zai-org/ZCode。同名工作台或社区分支应注明各自维护者与改动，不能当作同一官方发行版。
源码许可覆盖哪些内容？
仓库采用 Apache-2.0。第三方声明、模型 API、托管服务和发行版相关条件仍需单独核对，仓库的 NOTICE.md 提供了相关项目声明。
只看模型能力就能判断 ZCode 效果吗？
不能。工具配置、上下文组织、执行环境和修改审阅方式都会影响结果，应结合完整任务流程比较，不能以模型名称代替实际效果。
借鉴这些机制是否需要更换工作工具？
不需要。可以先将 ZCode 作为任务结构、工具边界和结果审阅的设计参考，在已有工作流中验证思路。软件复用是另一项选择，需要核对兼容性、权限与许可；借鉴设计思路不会自动完成软件与 Floatboat 的连接。