1. Demo 简介
数字员工办公区 是一个面向 AI 协作办公场景的 Web Demo。它把多个 AI Agent 不再藏在一个个聊天框里，而是变成一个可观察、可分工、可追踪、可交付的“数字员工团队”：组长负责澄清需求和拆任务，前端、后端、文档、测试/交付等岗位各自接活，系统把整个任务过程用 3D 办公区、任务流转面板、全景协作图和最终交付产物展示出来。
这个 Demo 主要面向三类用户：
- 想把 AI 编程助手从“单个问答工具”升级成“协作团队”的开发者；
- 需要给团队、客户或评审演示多 Agent 工作流的产品/技术负责人；
- 希望用更直观方式理解 AI Agent 分工、状态、任务进度和交付结果的普通用户。
当前版本的核心能力包括：
-
3D 数字员工实时状态图
系统中有 Claude Code、Codex、Trae CLI、Hermes、OpenClaw 和前台小雅等数字员工。每个员工都有工位、岗位、任务、思考文本和实时状态。用户可以在 3D 办公区里看到谁正在工作、谁在思考、谁在休息，也可以切换到卡片视图查看更密集的信息。
-
任务中心 Job 编排
用户不只是“点一下派活”，而是可以创建一个可追踪的 Job。任务会进入固定流程：接收任务 → 澄清需求 → 拆解计划 → 分派员工 → 并行执行 → 验收整合 → 交付产物。任务中心会展示当前 Job 状态、历史任务、组长追问、确认计划、重新规划、取消任务、最终报告和下载产物。
-
多场景任务处理
这个 Demo 不只适合写页面。任务中心可以按输入内容识别不同任务类型：技术页面、文档/PPT、Word 交付说明、Python/JavaScript 脚本、通用分析任务等。不同任务会进入不同分工路线，最终输出报告、脚本、文档或验收清单。
-
组长澄清与岗位分工
组长会先提出关键问题，也可以在信息不足时记录合理假设继续推进。规划阶段会根据岗位能力矩阵把任务分派给对应员工：前端负责页面结构和交互，后端负责接口与数据模型，Hermes 负责文档和汇报材料，OpenClaw 负责验收清单与交付风险。
-
全景协作图与过程追踪
每个 Job 都会生成 trace 事件，记录“谁在做什么、为什么分给他、当前执行到哪一步、产出是什么”。前端用任务时间线、节点气泡和全景协作图展示这些过程，让 AI 干活不再是黑盒。
-
交付报告与可下载产物
Job 完成后会生成最终 Markdown 报告，并写入
outputs/jobs/<jobId>/。对于脚本类任务，可以生成 Python / JavaScript 脚本产物；对于 Word 文档类任务，可以生成可下载的.docx文件。实验模式下还可以允许员工修改当前项目文件，但必须先确认计划，不会自动提交或推送。 -
多 CLI / 多 Agent 内核扩展
当前演示版已经把前端展示、Sidecar、Agent adapter、persona、任务编排拆开。也就是说，底层不是只能服务一个聊天助手，而是可以承接多个本地 CLI / Agent 内核。演示环境中优先保证稳定体验，完整架构则面向 Claude Code、Gemini CLI、Codex、Cursor CLI、Trae CLI、Qoder CLI、OpenClaw、Hermes 等多工具协同。
这个 Demo 的目标不是做一个“更花的 3D 页面”，而是把 AI 协作从“看不见的后台推理”变成“能看、能追、能交付”的工作流体验。
2. Demo 创作思路
最开始的想法很简单：现在大家都在用各种 AI 编程助手，但它们大多还是聊天框或命令行形态。能力很强，可是过程不直观。
当一个用户说“帮我完成用户管理页面”时，背后其实包含很多角色：有人要澄清需求，有人要拆任务，有人要做前端，有人要设计接口，有人要检查验收，还有人要把最终结果整理成可交付报告。如果这些过程都挤在一个聊天窗口里，普通用户很难判断任务到底推进到了哪一步，也很难理解多 Agent 的价值。
所以我把这个项目做成“数字员工办公区”：
- 用 3D 办公室表达每个 Agent 的存在感；
- 用岗位和人格区分不同 Agent 的能力边界；
- 用任务中心把一次“干活”拆成可追踪 Job；
- 用全景协作图展示组长如何调度其他员工；
- 用最终报告和下载产物把过程收束成真实输出。
产品的底层思路不是“做几个 AI 头像”，而是做一个本地 AI 员工调度台。每个员工可以对应不同的 CLI、不同的模型、不同的权限和不同的工具链。现在的演示版优先把编排、状态、交付和可视化跑通；后续可以把 Gemini CLI、Codex、Cursor CLI、Trae CLI、Qoder CLI、OpenClaw、Hermes 等接进同一个调度层，让不同 Agent 像一个真实团队一样协作。
3. Demo 体验地址
体验方式：交互式 HTML Zip 文件（社区附件上传）
digital-employee-experience.zip (4.0 MB)
本次提交的 Zip 是可直接打开的静态体验版，内置演示 Job 数据，重点展示 3D 数字员工办公区、岗位状态、任务中心、Job 流转图、节点详情和可下载产物入口。
为了保证评审打开即能体验，静态体验版不会直接调用评审电脑上的本地 CLI。完整 CLI 能力需要启动本地 Sidecar 后体验。
本地完整体验方式：
npm install
npm run setup:bridge
npm run dev:all
浏览器打开：
http://localhost:5173
如果只打开 HTML Zip，可以体验演示模式下的 3D 办公区、员工状态、任务中心、流转图和示例产物。启动 Python Sidecar 后，可以体验本地 CLI 探测、员工会话、真实 Job 编排、任务流转、最终报告和脚本 / 文档产物生成。
4. TRAE 实践过程
这个项目从创意、项目搭建、质量审查到 Job 编排优化，都是围绕 TRAE 的任务会话推进的。我保留了关键任务截图和 Session ID，下面按开发过程整理。
步骤一：项目搭建与需求拆解
一开始先把需求从“3D 展示多个本地 Agent 状态”拆成三个阶段：第一阶段做 3D 办公区、员工列表、任务显示和点击对话；第二阶段补齐相机限制、卡片/工作台视图和资源管理；第三阶段加入员工闲聊、接水、看鱼、上厕所等模拟行为，让 Demo 不只是一个静态看板。
Session ID：
.1998254018407680:af001577332a5fbc2a8f0da67e04a887_6a3ceb3f55d93841c839d98b.6a41cafe69b075519c0e6557.6a41cafef9e65e08aaa6de66:Trae CN.T(2026/6/29 09:31:42)
步骤二：接入本地智能体与 Sidecar 架构
第二步把项目从纯前端演示推进到“本地智能体集成”。前端保持 React + Three.js 体验，后端用 Python Sidecar 承接本地 CLI 调用、会话流、员工 persona 和 Mock 降级。这样即使本地没有 CLI，Demo 也不会完全失效；有 CLI 时，数字员工就可以进入真实对话和任务执行链路。
Session ID：
.1998254018407680:c88f5e651ee85be153c081e267be273d_6a3ceb3f55d93841c839d98b.6a41d35069b075519c0e675f.6a41d350f9e65e08aaa6de67:Trae CN.T(2026/6/29 10:07:12)
步骤三：高能力模型审查与交叉验证
初版完成后，我没有直接继续堆功能，而是让高能力模型从代码逻辑、性能、内存、交互体验几个维度做系统审查。审查过程识别出对话流程、3D 资源释放、任务分配、状态同步等风险点，并通过交叉验证整理出优化清单。
Session ID：
.1998254018407680:61d6dc347b469ce6b635ea49ea94abcc_6a41cf0f69b075519c0e66fa.6a41f2e269b075519c0e71b7.6a41f2e2f9e65e08aaa6de6b:Trae CN.T(2026/6/29 12:21:54)
步骤四：多智能体工作流协调能力
最重要的一次迭代是把“派活”从单点任务状态升级成真正的 Job 编排。通过 TRAE 会话，我重新梳理了组长、前端、后端、文档、测试/交付之间的分工关系：组长不再只是一个被派活的人，而是任务入口和调度中心；其他员工围绕 Job 节点协作，最终交付报告和产物。
Session ID：
.1998254018407680:964e6f663b2c3c24bc2bb63a21536d16_6a4203a169b075519c0e7379.6a4203af69b075519c0e737b.6a4203aef9e65e08aaa6de6d:Trae CN.T(2026/6/29 13:33:35)
步骤五：任务流转图与可下载产物打磨
最后一步重点打磨 Job 的展示和交付体验：把任务面板从左侧员工列表里拆出来，单独放到右侧任务区域；把任务过程做成更清晰的流转图，让用户能知道当前处在哪个节点；点击节点后可以查看对应员工的职责、思考和执行内容；同时把脚本、Word、JS、Python 等任务结果整理成可下载产物，让 Demo 不只停留在“看起来在协作”，而是有明确的交付文件。
Session ID：
.1998254018407680:f69514d938f9ad2652ac95010c73e191_6a433b83dbfe3c6a1ab455c7.6a4346b4dbfe3c6a1ab460a1.6a4346b481c1abf9728ec1da:Trae CN.T(2026/6/30 12:31:48)
5. 开发心得
这次最大的收获是：多 Agent 产品最难的地方不是“有几个 Agent”，而是如何让用户看懂它们为什么存在、怎么协作、交付了什么。
如果只把多个模型头像摆在页面上，它还是一个包装过的聊天工具。真正有价值的是把任务过程结构化：组长提出问题，系统记录假设，计划被拆成岗位子任务，员工产出被汇总，最终报告和文件可以下载。这样用户看到的不只是“AI 回答了我”，而是“一个 AI 团队完成了一次可追踪的工作”。
数字员工办公区验证的是一个更大的方向：未来本地会有越来越多 CLI 和 Agent 工具，它们不应该彼此孤立。一个可视化的 AI 员工调度台，可以把 Claude Code、Gemini CLI、Codex、Cursor CLI、Trae CLI、Qoder CLI、OpenClaw、Hermes 等工具组织起来，让不同能力的 Agent 像团队一样协作，而不是让用户在不同工具之间来回切换。
通过的报名帖链接：