Skip to content

Anna Development Diary

Jump to bottom
Foxclaw edited this page Aug 25, 2026 · 1 revision

Anna Development Diary / Anna 开发日记

时间：2026 年 6 月中旬至 2026 年 8 月 24 日

项目声明

这是一份 AI Product Manager 推动产品从 0 到 1 的开发日记，也记录了我在产品判断、技术理解、架构取舍和验收标准之间的挣扎。

模型在持续迭代，开发能力不断增强；单人的认知、决策和上下文整理速度相对缓慢。在一些阶段，我成了 Anna 产品开发的瓶颈。每一次推翻、重构、暂停和重新出发，都来自我对产品理解的继续变化，也构成了 Anna 的真实开发过程。

Anna Development Diary 将持续更新，记录后续版本中的产品决策、开发进展、失败、验证、重构与发布边界。

Anna 是面向小型团队协作的 AI Agent。项目从报销、财务看板和外部业务系统连接起步，逐步形成 Chat、Cowork、Create、Crew 等产品能力，并通过多轮重构建立 Event Store、ToolGateway、Memory、Trace、Eval、Scheduler 与 Runtime 恢复机制。2026 年 8 月 24 日，Anna 发布 v0.2.0 Developer Preview。

项目方向、产品定义、需求拆解、验收标准与发布决策由 AI 产品经理主导，工程实现大量借助 Claude Code、Codex 等 AI Coding Agent。Hiker 等合作项目保持独立归属，未验证能力保持明确边界。

阶段总览

阶段 时间 主题
0 · 起步对齐 6 月中旬 Windows 优先、Hermes 基座、Git 整理、真实性原则、报销 MCP 计划
1 · 报销打通 6 月 16 日前后 Agentic Chat、发票上传、报销审批、工具过程可见与可干预
2 · 演示数据与财务看板 6 月 18 日前后 demo-erp、财务问数、图表看板、Associate 与 Agent 集群设想
3 · Hiker 与 Associate 6 月 21 日至 22 日 模型切换、多租户、报销反写、Hiker 全球客户、Electron
4 · Harness 定位澄清 6 月 23 日至 24 日 ReAct、Hermes 与 Anna 边界、AIOS 定义、自我进化方向
5 · Forge Harness 重构 6 月 25 日至 7 月 2 日 L1–L7 分层、并发、可观测性、ReAct 五层图谱
6 · Iris 前端重构 7 月 6 日至 11 日 Chat / Cowork / Create、Runtime 三级下钻、登录页与设计语言
7 · Runtime 长程运行与评测 7 月 11 日至 14 日 长程诊断、评测体系、Loop Engineering、流程图与组件化输出
8 · Memory 与 Crew 重规划 7 月 15 日至 16 日 多轮线程、Memory、业务提示词、Crew 与 Asana 路线
9 · Crew 搭建与实测 7 月 20 日至 21 日 任务图、产物、Review Gate、@分派、Canvas 可用性
10 · 品牌升级与架构转向 7 月 22 日至 8 月 7 日 Anna 人格、Pi Agent 学习、暂停 Crew、外部评测接入
11 · 跨设备迁移与 Harness v2 决策 8 月 16 日至 17 日 Windows → macOS、一个 Channel 一个 Anna、Pi Loop Kernel
12 · Harness v2 分阶段重构 8 月 18 日至 20 日 Event Store、ToolGateway、Memory、Trace / Eval、Scheduler
13 · MVP 验收与公开发布 8 月 21 日至 24 日 T07 / T08、证据分层、发布门禁、登录页、Developer Preview

主题索引

主题 时间
Harness / Runtime / ReAct / Agent Loop 06-23 至 07-15、07-23、08-05 至 08-24
底层架构定位与多轮重构 06-24 至 07-02、08-05 至 08-20
Cowork、Finance 与 Hiker 06-18 至 06-22、07-11 至 07-16
报销、发票、审批与反写 06-16 至 06-22
Crew / Associate 项目协同 06-18 至 06-22、07-16 至 07-21、08-05、08-17、08-24
前端、Iris 与登录页 07-06 至 07-22、08-24
Runtime 可观测性与 Trace 07-07 至 07-15、08-05 至 08-24
Memory 与 Context 07-13、07-16、07-23、08-05 至 08-20
Evaluation 与发布门禁 07-12、08-06 至 08-24
模型、Tool、Skill 与权限 06-21 至 06-25、07-11、08-17 至 08-22
跨设备开发、Handoff 与 Context Rot 08-16 至 08-21
GitHub 与 Developer Preview 08-21 至 08-24

前期探索与产品演进

起步：切换 Fable5 与第一次对齐

Windows 优先 · Git 整理 · 前端大改(参考 Claude Desktop) · Hermes 为底座 · 拒绝假数据 · mimo 模型

  1. 我们可以先做个 Windows 版本，在当前环境下进行测试，后期迁移到 Mac 上；

  2. 完成 Git 仓库，整理目录和层级结构；

  3. UI 保留现在的中英混合，I suggest to keep the unique characters like MCP, Skill and others. 这些已经是业内公认的词汇了，没必要按照 Chinese 的说法。

  4. 整个项目的前端要大改，风格参考 Claude Desktop APP. 现在的样子太像杂乱的 B2B 表单系统，Ugly design, u need to help him to improve.

  5. Anna 的核心是要运行起来，所以尽快完成项目的全面整理和修改，尽快落地运行，底层是 Hermes Agent 的源码，不需要自己去造一套 Harness 系统，调用和改造为主。

  6. 你拥有修改一切内容和原始设计、代码仓库的权利，由于多人的参与和编辑，这个项目现在进度缓慢，你需要指导我完成项目修改。

  7. 注意项目一定要保证真实性，拒绝假数据和假演示。

  8. 涉及到 LLM 和 Agent 的能力，统一使用以下配置：

    • 模型：mimo-v2.5-pro
    • API Key：[已脱敏：mimo API Key]
    • OpenAI 兼容地址：https://token-plan-cn.xiaomimimo.com/v1
    • Anthropic 兼容地址：https://token-plan-cn.xiaomimimo.com/anthropic

架构复盘与报销 MCP 计划

回顾架构硬伤 · 关注可拓展性 · 轻量化 · 出报销 MCP 打通方案(要室友配合)

  1. 回顾最初的设计文档，包括架构设计和产品设计，看一下整体有没有硬伤；

  2. 我非常关注底层架构设计，因为这决定了整个项目的可拓展性，请你回顾一下架构设计文档，站在你的角度审查一下现在的架构和产品功能是否匹配，是否需要调整，如需调整，直接站在架构师角度结合 Hermes Agent 进行调整。 ；

  3. Hermes Agent 是我们选定作为基座的底层架构，是因为这一套 Harness 的综合能力，他 GitHub 的地址为：https://github.com/NousResearch/hermes-agent，你可以拉取一套到本地；

  4. 我希望 Anna 是轻量好用的，避免做的过重，请指导我并帮我继续修改。 你觉得让 Anna 正确高效运行且有必要修改的。 完成后修改 UI，我希望尽快看到新的 Anna

My roommate doubt the progress of our project, we need to finish Anna and make every function work well. But I still tell him as an architecture, Claude will fix the essential foundation of the project. So Claude, 你仍然需要确保整个项目是性能良好、可拓展、可二次开发、可组装、架构强大，是一套完整优秀的面向 2B 领域的 Agent Harness 系统。 我们要秉持 Agent Harness 的思想去搭建和完善功能，确保该调用 Harness 完成任务的是走 Agent 路线，走硬编码可以完成的走代码实现。 现在项目的实现和规划上，please help me to make Anna on the right way and work well.

我已经让室友准备好了他的报销系统，现在他正等待我的指令进行 MCP 的搭建，由于我们俩都不懂如何让 Anna 顺利通过 MCP 链接系统完成所需需求，目前也只有一个部署在云端的报销系统在运行，现在请你给我们一套完整的 Plan，指导我们进行打通。 你需要告诉我，需要我的 Roommate 提供什么、在他的系统上怎么做，做什么。

报销 MCP 跑通：从表单堆叠走向对话

表单堆叠被批 → Agentic Chat · CoT 可见 · 右侧沙箱 · 先派生分支验收再合并

这个界面室友对我进行了批判，他认为应该是结合对话式的，所有的 Agent 和任务执行比较像 Chat 中的样子，执行的过程如果是 Agent 调用，应该有 COT，有思考过程，同时支持沙箱在右侧展示。 目前这种展示方式过于原始，不美观，而且功能（引导、纠错、字段缺失、风险预警等等）并不是很明显，请 Claude 仔细研究一下差旅报销场景下的需求，结合室友的构思，重构一下这一部分的功能。 注意，先派生一个 Git，验收通过后再合并代码。

2026-06-16：前端、对话模式与报销审批

前端改造 · Agent 对话模式 · 差旅报销审批 · 发票上传与读验

  1. 修改前端；

  2. 修改 Agent 对话模式；

  3. 增加差旅报销审批。 当前的产品界面存在问题，Roommate 敦促我在功能全面展开前，进行大刀阔斧的改革。 现在功能跑通了，但是出现了很大的问题就是用户体验不佳，同时呢，和我们最开始的设计是相悖的。 我期望的是差旅报销这个模块的执行逻辑，应该是类似 Chatbot，或者 Claude Code 的 Code 模块一样，任务是通过对话式发起，执行过程和其他内容都在一个对话框内，通过思维链的方式一项项实现工具的调用、Skill 的调用、Agent 的调用等等进行执行，ReAct、Agentic Loop、Agentic Chat 应该是在一个，是一个 Agentic Chat 界面——用户通过对话与 AI Agent 交互，Agent 在对话流中自主进行 Chain-of-Thought 推理 和 工具调用（终端、文件、浏览器、代码执行等），通过 ReAct 循环 多步迭代完成复杂任务，全程对用户可见、可干预。 至于系统部分，需要硬性展示的内容，我建议放在右侧作为侧边栏展开。 现在发挥你的设计能力，先修改差旅报销这一个版块，当然，要确保 MCP 还能正常工作。 还有一个问题，没有附件上传。 所有的 Agentic Chat 都不支持附件上传，我觉得有必要开发一下，或许是支持，但是设计上没有体现出来。 差旅报销这一块，需要支持发票的上传，而且对方的系统也是支持发票的读取的，这一块怎么打通，发票应该在哪读，在哪验我们都需要一个解决方案。 先优化这个，我们测测。

演示系统：搭建 demo-erp

造 demo-erp 财务系统 · 参考 SAP/Salesforce · 出需求文档给室友开发

目前我们已经基本打通了差旅系统的集成和 MCP 打通。 调取了 MCP 的数据。 现在我跟 Roommate 并没有一个真实的财务业务系统来获取数据，她正在开发一个真实的业务系统，或许目前为了演示我们可以自己造一个？ 所以你需要哪些数据，才能支持起完整演示 Anna 的功能呢，注意我们后期会切换到她的真实业务系统，现在我们快速搭建一个简单系统来支持演示。 现在给我一个需求文档吧，我们去建设。 因为你的能力比我的 Roommate 强，所以我希望你能整体详细的规划这个系统，有哪些模块，有哪些数据，并且帮我设计一些数据。 结合中小型企业真实业务场景和后台的财务、业务经营系统，类似 SAP S4/Hana, Salesforce 等的业务系统，我们需要准确、好用、功能全、数据对，这个系统要具备基本的运行能力和业务逻辑。 请你完整规划，详细设计，给出一系列文档，我让 Roommate 照着开发。

财务经营看板：可视化与自然语言问数

看板图表化 · Anna 财务问答平权 · 前端架构优化 · 左栏固定 bug

目前财务经营看板已经打通，但是功能上只实现了第一步，即数据拉通。 第一，接下来，你需要首先对页面尽心优化，现在的这个页面很丑，而且没有图表，全是数字，人没有重点，作为财务人员，我看上去是没有着眼点的。 第二，我需要你增加 Anna 对于财务经营看板的问答，我要让财务知识平权，通过自然语言问答的方式可以实现查数、问数、解析、洞察、分析报告等等。 第三，完成前两项后，整体考虑前端设计，设计架构上是否可以优化，是否可以以更灵活的框架展示内容？ 先减重，然后看一下 Gittree，提交代码合并一个版本，然后我准备给 Roommate 审核

有个全局的问题，就是无论是 Chat Cork 还是 Create，我左侧栏位都会随着右侧内容滑动，划到最下边才能看见 Admin，左侧应该是固定的才对，看一下这个滑动效果，检查和修复一下，修复完了在发布一版，我去评审。

2026-06-18：联调、看板整合与 Associate

联调联测 · ERP 与 Anna 同机部署 · 合并 Kanban+财务助手 · Associate · 叙事

  1. 完成联调联测；

  2. 把简易 ERP 系统部署到 GitHub 上（X）；改为跟 Anna 一起部署，这样走本地端口调用更快。

  3. 如无特殊 Idea，或许合并 Kanban 和财务问答助手；

  4. Associate 功能开发；

  5. 继续优化 UI；

  6. 开始思考叙事方式，如何讲故事。

Agent 集群设想

Agent 独立→集群(Marvis 类) · 解耦为改 Harness+Agent · demo-erp 上 GitHub 探索

现在的 Anna 有个问题，就是 Agent 之间是相互独立的，好处是这样确保每个任务调用的内容是不出错的，因为独立建设。 坏处是后期模型增强后，每一项任务都要单独调整。 所以，我们可能需要在逐渐完善后，增加一个可以调用的 Agent 模块，类似 Marvis 的 Agent 集群，后期还是让 Anna 自主调用不同智能体来完成任务。 这样就从改模块进一步解耦为，改 Harness 和 Agent。 我现在服务器资源略微紧张，我现在在思考这个 demo-erp 是否可以部署到 GitHub 上。 如果可以的话，帮我探索一下，并帮我部署上去，我拥有 GitHub 的账号。

2026-06-21：模型切换、Associate 与多租户

GLM-5.2 · tab 切换丢内容 bug · 默认当月看板 · BI 美化 · Associate 场景(太古 MRO) · 多租户 · SOP · DeepSeek · Electron

先帮我启动 Anna，我整体看一下。 另外，我会把 Financial ERP 进行单独的部署，我现在在思考，我是否可以把这个 ERP 系统跟 Anna 放在一个服务器上。 我现在正在思考产品的优化，现在 Anna 的财务看板跟财务助手，功能上似乎有相同之处。 你觉得从业务上这两个功能是否需要合并？ 不用迎合我的爱好，我们这是一个 Teamwork，我们要探究最正确的路径。 先帮我更新一下这个 Financial ERP，并且帮我打个包，我要进行远程部署了

我的 Roommate 希望使用更强的模型驱动 Anna，并在 Chat 和 Create 中支持模型切换。

  • 主模型：GLM-5.2
  • API Key：[已脱敏：GLM API Key]

处理一个 Cowork 的 Bug，每次我 Side Tab 从 Cowork 换成 Chat，之前的看板内容、问题全部消失了，再次点击需要重新加载，这是个很影响体验的问题。 很遗憾没有修复，你可以自己试一下，Roommate 反馈，在使用 Cowork 的看板询问完问题后，进入差旅和 Associate，回来之后看板和侧边栏提问都已消失。 需要重新修复这个问题

另外启动时，能否直接帮我接上看板，默认为当月数据，后期我们的看板也会和 Anna 一起部署，其实这在逻辑上是反的，因为应该先有 ERP 再有 Anna，Anyway，帮我优化。 另外看板的前端还是很丑，这个折线的图表让我的 RM 吐槽了，你最好学习一下顶尖的 BI 看板如 Tableau 的看板看一下怎么布局最合适，怎么呈现业务最合适。 我们现在准备做一下 associate 的功能设计，你先看一下现在 Anna 的能力和最开始对 Associate 的设计，我感觉目前这一版并不是我想要的。 但是有一点你做的特别棒，就是 Chat 推 Associate，我们后边也希望能和一些 IM 工具，如 Lark 或者 Telegram 这类连通，这样我就可以在群里@各种人分配任务了。 这个 Associate 和我之前在太古飞机做飞机的 MRO 有关，他就是把飞机的各项检修任务和人员资质做了管理，然后做了日计划和管理，提升了整体的管理效率。 我也需要你帮我判断一下，是不是把 Associate 从 Cowork 的 tab 里边拿出来，放在一级菜单里的 sidebar 里。 其实 Associate 我最开始的设计初衷是，解决项目制任务，我简单说个场景，你体会一下：我们现在要做一个新的产品设计（软件或者营销类物料）这会涉及到多方的协作。

  1. 任务拆解部分：我（现在是 Boss）设计了这个任务，我需要 Agent 帮我将任务拆解（我们会假设预制一些标准流程和最佳实践一些 SOP）和做 Workflow，给出任务路径和关键节点；

  2. 人员分配部分：这个时候 Agent 还需要结合我们团队里的人员的属性能力技能进行分配（有 PM、有前端有后端有 UIUE，有设计师，有外包供应商等等）；

  3. 任务分发部分：通过 IM 工具（websocket、Webhook 或者邮件）通知相关人员（人员可能反馈没有时间，或者需要协调，我们还需要做反向的调整和安排，要有反馈，但是 MVP 这个反馈可以是人为“我”Boss 进行调整）；

  4. 任务执行部分：可视化结构看大家做到什么程度了（可以是个小房子里边有好几个员工，跟个游戏界面一样的小小办公室，看大家在干什么，Tencent 有个 Marvis 的产品有类似功能），由任务当前的进度和员工的反馈组成，任务触发下一个节点了，就能下推到下一个人（比如完成了 Product 的 PRD 推评审，审不通过返回改，改完推 UIUE 设计等等）；

  5. 内容优化：这本来就是对员工项目制工作的自动化拆解、分发、执行监督、反馈优化、进度可视的一个项目，未来部分员工会替换为 Agent，由 Anna 直接调用 Agent 进行任务接管。 不一定完全都是人类员工。 现在，结合 Anna 的现状，先做整体的分析，然后做这个功能的详细分析理解和计划。 给我出一份你下一步要做的事情，我要交给 Roommate 进行评审，帮我补齐我没想到的事情，完善功能，但也要考虑当前 Anna 架构、能力等等，综合考量最后的呈现结果。 但我仍然希望你能完美的实现这个功能。 可信 Demo 但是要尽量做全，这个功能很复杂，甚至可以单独出一个产品比如 Asuna，好吧我也是受 Asuna 的影响，所以设计时候我们可以参考一下他的设计和架构、前端，现在给我你的看法和建议我们做到什么程度。 另外我想把 Associate 也换个 C leading Word。 结合我的看法继续

关于通知的那部分，我觉得如果使用 Websocket 打通太复杂，我们就先发邮件。 另外分发接到通知，我以后是希望做到 Anna 中，毕竟大家会一起使用 Anna 的一个 Team Business，这样直接在 Anna 中交互也行，也好解释。 这样执行和评审都在 Anna 中，是不是简单一些了？ 在我这个思路上你觉得是不是可以在优化一次。 U get me, love from Singapore. 我们的 Demo 可以通过一套用户系统来解决。 我们现在其实还没有做用户做租户数据分离，也没做 Business Team 模式，这些正好一起做了。 通过登录不同的账号，完成任务。 好的继续你的任务。 a) 旧「 Cowork 」不要改名「经营/Finance 」,保留 Cowork，后边还可以键入供应链、制造等其他 ERP 系统，不限于财务。 b) MVP 权限模型做多细(就 Boss/成员两档) c) 小办公室 V1 做到什么保真度(静态状态卡 → 轻动效 → 像素小人 即可，参考一下 Marvis，在资源有限的前提下做到最好) d) SOP 模板第一个除了「产品设计」,可以再带一个「营销物料。 注意前端设计的合理性，美观程度。 没问题，他看过了，请你执行。 然后进入开发阶段，开发时记得使用 SubAgent 同步进行开发。 回顾一下整体，看一下下一步应该做什么比较合适，我需要你帮助我设定计划，确定开发节奏。 You can just audit some demo person with diffrent role and skills, and to fit the Crew demo

帮我验证一下功能，自己使用自查一下，然后确定没问题，合并代码，启动

DeepSeek API 使用 OpenAI / Anthropic 兼容格式。模型接入后开启 High Reasoning，并重新完成运行验证。

参数 值
模型 deepseek-v4-pro
OpenAI 兼容地址 https://api.deepseek.com
Anthropic 兼容地址 https://api.deepseek.com/anthropic
API Key [已脱敏：DeepSeek API Key]

先帮我提交一版，合并一稿 Electron 的桌面版，我准备交付 Roommate 评审

2026-06-22：Create 优化、报销反写与 v0.0.5

MacOS Electron · Create 对话式+沙箱 · Crew 测试 · 报销反写(审批链/角色映射) · 连接器自动拉起 · 自动登录 · v0.0.5

增加 MacOS Electron

  1. Create 优化，改为对话式界面，主要强化沙箱，把 Hermes Agent 能力全部接入；强调一些业务上的特化能力；融合 Lingee Build 的护城河能力；

  2. Crew 测试，UI 丑，交互方式不合理，应该是参与任务换办公室，不参与办公室就自己一个人，这是交互的问题，后边可以优化前端和路径的问题；

  3. Hi, a new week right? My roommate has a new requirement, the reimbursement sys of Anna 的反写操作，看看能否用 Anna 去操作差旅报销系统，获取审批流，也就是 Anna 不仅可以上传差旅报销的需求，也可以远程操作审批，这样可以和 Anna 自身的员工和领导的角色权限系统共同使用起来，同时功能也更完善；请你(和室友)过一遍 spec,尤其确认这几个点要不要改:

角色映射:默认 boss=审批人、member=仅提交 —— 你们的"领导"是否就对应 boss，不一定，我们需要管理员设定审批角色（分配财务审批人员），但是默认 Boss 具备审批能力，审批链:按"有序多级步骤"设计(兼容单级/多级)—— 室友系统是多级审批 批量审批:Phase 1 支持"批了第 2 单/这几单都批了",但每单是独立的受治理写(非原子批量)—— 可以 室友 MCP 现状:他的报销系统现在已经有审批流(审批人/审批链/状态)

把这个 ERP 连接器做成跟 Anna 一起自动拉起

先帮我修改一下登录，现在我们还是在本地，自动帮我填写账号密码，不要让我一遍遍输入了，等正式发布再删除。 帮我检查一下 Gittree，确保 Anna 的代码为最新，并删除一些无效冗余代码，厘清架构与功能，然后打包一个版本，命名为 0.0.5，告知 all sessions in Anna Group of Claude Code, now we use 0.0.5 as the current version.

2026-06-22：Hiker 全球客户接入与 v0.2.0

Hiker MCP 新系统 · Cowork 开发适配 tab · Hiker 全球客户(看板类)

Hiker MCP，Roommate 给了一个全新的系统，整个系统包含的内容如图，他希望我在 Anna 的 Cowork 上更新一个功能能够打通他的 MCP，并且给我了他的 MCP 文档，你可以看一下，我感觉他的产品也是看板类产品，所以我需要你：

  1. 阅读他的文档，结合图片看下 Hiker 是个什么系统；

  2. 在 Cowork 中开发一个适配他的 tab，你需要思考我们打造一套什么系统来适配他的系统，同时体现 Anna 的设计思想和产品功能特性；

  3. 确定设计方案；

  4. 开始设计。 The tab name is Hiker 全球客户, and my roommate gives me the new mcp file, u can check and optimize the tab

2026-06-23：Code ReAct 优化与初心

初心=自进化 Harness · Code CoT/ReAct 优化(参考 CC) · Code 沙箱 · Hiker 跑通 · 前端

初心：打造可以自我进化的 Harness

待优化项：

  1. 完成 Code 的优化，完成 CoT 和 ReAct 的优化，现在的思考逻辑太碎；同时研究明白到底什么是 ReAct，为什么可以这样思考，我希望全面参考 CC 的 ReAct 框架，能够给用户点选，把调用部分隐藏。 保留用户选择和检查的能力，越少动脑越好。

  2. Code 要有沙箱，完成沙箱的测试和对比；

  3. 完成 Code 之后，优化 Hiker，跑通即可；

  4. 优化整体的前端体系和表现，这个优先级放在 ReAct 之下。

2026-06-24：自我认知与 AIOS 定义

Cofounder 参考 · "研究你自己"(CC 体系/CoT/Agent Loop) · Hermes vs Anna · AIOS 九点定义 · 抹去 Anthropic 痕迹

新产品：Cofounder，概念可以参考，https://www.aiverse.design/browse/cofounder-processing-steps 参考 Cofounder 的登录界面，修改整个 Anna 的 CoT 和状态机。 Crew 的人员计划可以采取类似时序图一样的多级分流，做好可以做成动态的，在产品逻辑上参考 Claude Tag 后期可以加 IM 工具（复杂度极高，暂时不做）

My roommate already checked Anna, he had some problems and need to optimize, I can show u what we are thinking:

  1. 我们现在所有连接大模型的应用中，如 Chat 如 Create，甚至是财务看板等中的问 Anna，这些使用的 CoT 思维链是一致的么？

  2. 思维链现在是有什么决定的。

  3. 我们希望先学习和了解一下思维链的问题，然后对 Anna 所有的 CoT 进行优化，我甚至认为，这一套思维链是不是才是 Harness 中比较比较重要的一部分？

  4. 我们是否可以修改 CoT，他和底层的 Hermes Agent 有什么差异？ Ok, nice teacher, but i and my rm have not learnt about these. So we are curious about，Claude Code 也就是你自己现在的这一套 Harness 体系，你的 Chat/Cowork/Code 这三者的体系是怎么规划的，你的 CoT 是怎么进行分配的，你底层的 Harness 又是怎样的。 我希望你能研究自己，或者结合对于 Claude Code 的专业分析和拆解，以你作为标准，告诉我现在这套体系是怎么做的。 毕竟你是最好的榜样之一，我们希望参考。 Claude Code 怎么做 Anna 现在 差距/建议

1 份薄的共享 base system prompt，全 Code 通用 6 份各写各的 inline system prompt 🔴 最大差距：抽一个共享「 Anna agent base 」（统一 persona + 全局护栏：拒绝臆造/数据必标来源/只用白名单工具），各 orchestrator 在它之上拼。 Skills 承载领域知识 已有 Skills（SKILL.md） 🟢 已对齐，保持。 Skill 渐进式加载 把整个 Skill 注进提示 🟡 当前规模没问题，记为未来扩展杠杆。 治理外化（permission/hook） 已有审批/审计/工具白名单 🟢 已经很强，甚至比很多产品狠。 "想多深"由模型+thinking 预算决定 MAX_ROUNDS 每功能写死（0/1/4/6） 🟡 可收敛成一条共享策略 + 按风险调 reasoning_effort。 Subagents 隔离上下文 orchestrator 单发 ⚪ 可选的未来能力，现在不急。 Nice teacher, lovely lesson for us, and Anna did correctly, right? RM and I still want to know when I ask u something, u always firstly thinking then tool calling and check and plan what to do, how can I call this process, the Agent Loop? I dont know. So 为了我们定位问题，我们还想请你继续思考和教导我们。 你在收到一条问题或者优化建议后，做了什么，这些分别有哪些部分决定，我们如果希望修改的话，应该怎么改，是否可以改，改哪里，专业名词叫什么。 Teach me，thx

我可能会继续问，我跟 RM 非常渴望正确且真实的知识。 我们想问 Harness 发挥了什么作用呢？ 哪些是模型决定的，哪些是 Harness 决定的，还记得么，Hermes Agent 是我们的底层，但是现在我不知道他是否还在发挥作用。 Oh, amazing, what i think before is that Hermes Agent is the architecture of Anna, because this part is maken by my RM, so compare with Hermes Agent and Anna, which one is better now? Do we need to learn Hermes Agent to optimize Anna? 请帮我和 RM 整体盘点一下，你应该也可以在 GitHub 找到 hermes Agent 的内容。 我希望我们是真实的，毕竟我们是为了整个项目更好。 其实现在的 Anna 已经超出 RM 的架构能力了，早期的规划是很好的，但是当时并没有想到后边会有这么多功能。 我来说下我的想法：我希望 Anna 能有 Claude Code 一样的 Agent 能力，我认为这是底座，同时在这套底座之上，我们特化了企业级的 Agent 应用和更加垂直的业务产品。 所以这也是我们为什么规划了 Chat Create 这些通用 Agent 能力。 但是目前我们确实花了很多精力去做 Cowork 的内容，因为这是体现差异化的地方，所以希望先做。 所以我有个隐忧，也是为什么我会和 RM 去检查 Agent loop 去看 ReAct 框架，因为现在的 Anna 太简单了，这样他的通用任务执行能力就会很差。 我们选择 Hermes Agent 是因为相较于 OpenClaw 或者 Pi Agent 这类框架，hermes 拥有自进化的能力，其实也是对标 Claude Code 的能力啦，我们始终是想以 Claude Code 作为底座，但是没有完整的开源代码嘛。 Hermes 可以自进化（我们认为可以帮助业务领域来创造技能，持续优化路径，记住业务规则等等）所以现在请你综合考量一下，我们在现在项目持续的开发与迭代中，下一步，我们还会继续完善 Chat Create 以及 Crew 中的能力。 所以在这个阶段我们需要矫正方向，你来评判，目前项目超出我们俩的能力了，你需要给出指导和建议，我们来做取舍。 （待办事项：最好看一下 2.1.88 的 ReAct 框架跟 Agent Loop 是怎么写得，直接做借鉴）

我们接受模型更换，后续也会切换其他更强模型，Mimo 只是现在实惠的选择同时也是基准测试，如果 mimo 跑通，其他更好的模型效果会更好。 我们不强绑定某一家模型厂商

我们之前合规获得过 Claude Code 的部分代码，项目地址为https://github.com/Foxtailsss-Andy/Thats-claude-code，我希望你看一下，这套仓库是否有用于我们的项目

这是编译 CC 的代码，我们不商用，仅学习，我现在需要你分析一下这个代码结构和内容，告诉我以下内容：

  1. 这套源码有什么，有哪些内容？

  2. 我如果想优化我的 Harness，这里可以给我哪些参考？

  3. 我特别想优化我的 ReAct 或者说 Agent Loop 流程，这里是怎么做的？ 我想问下，在这套代码里，Orchestration、Memory、Context、Agent Loop、Tool、Hook、Evaluation 以及 Sandbox 是怎么做的？ 你是否可以找到对应代码、结构、Prompt。 我并不是技术背景，但我想弄清楚这些内容。 现在，我们会用大量的时间来重新校对在开发和沟通了一段时间的 Anna，我们对于新架构、新功能的想法。 先说一个底层的构想，我们希望 Anna 是可以伴随最新最热的 AI 行业发展不断演进的，这种发展体现在架构的灵活性上，我们不希望她和任何一个产品、品牌、系统强绑定。 现在，Anna 的发展已经超过我和 Andy 的开发能力，需要你作为我们的 team Supervisor and Teacher 来监督和优化。 接下来，是我们的构想，请与我们一起创造：

  4. 我希望把 Anna 定义为企业级的 AI 操作系统（LLM+ToB 特化 Harness+业务 Agent+Loop Engineering），也就是说 Anna 不仅具备通用 Agent 能力（问答）、Vibe Coding 能力（Create），还是面向企业系统（ERP、SCM、MES 等），具备连接、读取、操作、反写、审核等全套企业级业务执行能力的（Cowork）；同时更支持我们在 Anna 这个平台上持续开发新的企业级的提效工具，如项目分配与协作工具（Crew）等等；

  5. Anna 的底层应该是通用 Agent 能力，也就是 Harness，Anna 具备完整的 Orchestration、Agent Loop、Memory、Skill、Tool Calling、Hook、Sandbox、Evaluation etc；后续我们通过持续的优化，强化平台能力，实现整体的持续优化；

  6. 在架构上，我们是应该是分离的，Chat 调取 Anna Harness 的一部分能力，Create 调取一部分能力，Cowork 调取能力通过 MCP 进行能力复用。 所以重点是 Anna 本身足够强的 Harness，足够智能的 Agent 能力，Anna 是面向企业场景的而不是对 ERP 系统做特化的流程调优；

  7. 在业务上，我们将能力 Agent 化，Anna 像是中台负责编排和调用所有底层能力，Chat 是 Anna+所需特定能力（Chat Skill、Chat Prompt、Chat Memory etc.），Create 是 Anna+所需特定能力（Chat Skill、Chat Prompt、Chat Memory etc.）在 Cowork 中，因为链接了不同的系统，不同系统间的数据是不同的，所以 Anna 要支持不同 tab 之间通过不同的约束（Skill 或 Prompt）实现不同效果的导向和优化；

  8. 在开发逻辑上，我们希望整个 Anna 都能响应 Graph Knowledge 的思想，通过类似 Graph Knowledge Network 的思想指导开发，每个模块都有自己的核心，然后分级层级递推，相互勾连，相互建立关系，这是一种思想，不要求强制执行；

  9. 在人员权限的管理上，我们希望 Anna 是支持多租户的，不同角色登录后，在一个组织内工作，这样我们可以共通数据，同时 Crew 也会更好的调用角色和能力；

  10. Anna 希望学习 Claude Code 一样的 Harness 治理和 Agent 能力，但有 Claude Code（ToC）不具备的多租户、ToB 特化审核等企业级产品的能力；

  11. Anna 具备学习能力*Memory，我们希望在企业场景中的关键操作和重点进行价值抽取，帮助下一次的任务变得更好，形成 Loop Engineering；This is what I talk with Andy, and what we got these afternoon, I hope u think our words hard, and check the repository to find what we really want to do, give feedback and make us check.

这是一套代码，但是我现在需要你抹去所有代码中提到的 Anthropic 和 Claude Code 相关的痕迹，在确保代码逻辑和效果的情况下。 当然如果有无法抹除的情况，请指出，并告知我是哪些部分。

2026-06-25①：Forge Harness 重写与 L1–L7 分层

重写 Andy 代码 · L1-L7 分层表 · Capability=Agent · 并发问题 · 周末:Harness 跑起来+ReAct+Sandbox

Yes，这是一套极其完整的代码设计，是我们见过的最完整的 Harness 设计，所以你能在保留核心设计、核心逻辑、核心思想、核心架构、关键提示词、关键代码的基础上上帮我按照这套结构直接帮我重写一个版本么，我们希望用于分析与重建一套自己的 Harness 系统。 注意，我最终还是希望以这几个分类方式的文档呈现。

层级 定义 对应构想 当时的代码判断
L1 模型层 LLM 推理引擎，模型无关、可换厂商 底层构想（不强绑定） ✅ OpenAI-compatible 可换
L2 Agent Runtime / Harness Orchestration、Agent Loop、Tool Calling、Skill、Memory、Hook、Sandbox、Audit、Evaluation 点 3、点 8 🟢 8 件里 6 件已落地；Memory 弱、Eval 无
L3 Connector 层 统一接入企业系统（MCP），read / write / validate / verify，治理统一 点 4 🔴 一个系统一套代码，尚未统一
L4 业务能力 Capability Capability = Skill + Tool 集 + Memory 作用域；财务、报销和客户能力都是 Runtime 配置 点 5 🟡 Skill 机制存在，领域知识仍硬编码在代码里
L5 产品入口 Surface Chat、Create、Cowork、Crew 由 Runtime、Capability 与入口级 Skill / Prompt / Memory 组成 点 1 🟡 四个入口已经存在，前端尚未共享内核
L6 治理与多租户 组织、角色、权限与数据共享 点 7、点 8 🔴 已建模，尚未形成强制治理
L7 Loop Engineering 从治理后的操作中抽取价值，改进下一次任务 点 9 🔴 基本缺失，已有 Audit 数据作为原料

Nicely, thats correct understanding, and quite fit for the design of our blueprint at very first. 不过，对于 L4 业务能力 Capability 和 Harness 的集成方式我们还需要仔细考虑一下，我跟 Andy 还没决定如何将这一部分作为单独的 Agent 进行调用和管理，还是封装成单独的 Business Capability，但核心思想都是可以组装和单独加载、单独调试，调用底层能力互不影响。 So, actually Anna is quite complicated AIOS to build. You can our supervisor and the biggest developer of us. Check the thought of us and continue.

在架构上已经对齐，重点的 L4 是 Cowork 能力，目前已经确定 Capability 和 Agent 其实是一套体系，但是在架构上如何调用 Harness 并发存在差异化的争议。 同时，并没有开始考虑 Crew 这种多租户协同的情况。

  1. 问清并发问题，是不是 Kanban 运行，独占 Harness 进程，其他是否可以用，这个怎么拆：就是 CC 多个 Session 并行时是怎么处理的，其实我理解，模型可以并发，这个是可以并行的，需要问清楚；另外 Sandbox 在这个过程中有没有用，我需要问清楚 Sandbox 是否可以作为一个运行环境加载。 另外 tag 可否可以单独作为一套体系加载。 这个周末。

  2. 我需要解决架构问题，把 Harness 跑起来，ReAct 调成我期望的样子，Sandbox 的问题。

  3. 之后优化前端，变成 Cofounder 的设计。

  4. Tag 的 Prompt 需要单独设计。

2026-06-25②：并发下钻与 Harness 三支柱

并发下钻(每 tag=独立 Agent 并行) · Sandbox 作运行环境 · Harness Engineering 三支柱 · 吸收 Andy 代码

Yes，这是一套极其完整的代码设计，是我们见过的最完整的 Harness 设计，所以你能在保留核心设计、核心逻辑、核心思想、核心架构、关键提示词、关键代码的基础上上帮我按照这套结构直接帮我重写一个版本么，我们希望用于分析与重建一套自己的 Harness 系统。 注意，我最终还是希望以这几个分类方式的文档呈现。

层级 定义 对应构想 当时的代码判断
L1 模型层 LLM 推理引擎，模型无关、可换厂商 底层构想（不强绑定） ✅ OpenAI-compatible 可换
L2 Agent Runtime / Harness Orchestration、Agent Loop、Tool Calling、Skill、Memory、Hook、Sandbox、Audit、Evaluation 点 3、点 8 🟢 8 件里 6 件已落地；Memory 弱、Eval 无
L3 Connector 层 统一接入企业系统（MCP），read / write / validate / verify，治理统一 点 4 🔴 一个系统一套代码，尚未统一
L4 业务能力 Capability Capability = Skill + Tool 集 + Memory 作用域；财务、报销和客户能力都是 Runtime 配置 点 5 🟡 Skill 机制存在，领域知识仍硬编码在代码里
L5 产品入口 Surface Chat、Create、Cowork、Crew 由 Runtime、Capability 与入口级 Skill / Prompt / Memory 组成 点 1 🟡 四个入口已经存在，前端尚未共享内核
L6 治理与多租户 组织、角色、权限与数据共享 点 7、点 8 🔴 已建模，尚未形成强制治理
L7 Loop Engineering 从治理后的操作中抽取价值，改进下一次任务 点 9 🔴 基本缺失，已有 Audit 数据作为原料

Nicely, thats correct understanding, and quite fit for the design of our blueprint at very first. 不过，对于 L4 业务能力 Capability 和 Harness 的集成方式我们还需要仔细考虑一下，我跟 Andy 还没决定如何将这一部分作为单独的 Agent 进行调用和管理，还是封装成单独的 Business Capability，但核心思想都是可以组装和单独加载、单独调试，调用底层能力互不影响。 So, actually Anna is quite complicated AIOS to build. You can our supervisor and the biggest developer of us. Check the thought of us and continue.

在架构上已经对齐，目前我们想体现差异化的重点的 L4 是 Cowork 能力，目前已经确定 Capability 和 Agent 其实是一套体系，但是在架构上如何调用 Harness 并发存在差异化的争议。 同时，并没有开始考虑 Crew 这种多租户协同的情况。

  1. 问清并发问题，是不是 Kanban 运行，独占 Harness 进程，其他是否可以用，这个怎么拆：

  2. 就是我们参考的其实一直都是顶级设计 Claude Code，Claude Code 的多个 Session 并行时是怎么处理的，其实我理解，模型可以并发，原则上 Anna 的 Cowork 中的各个 Tag 是可以并行的，各自通过 MCP 连接不同的 ERP 系统，然后通过每一个 Tag 的“问 Anna”其实也是并行的，这部分并行要问清楚；

  3. 我们期望最终每一个 tag 就是一个单独的 Agent，它可能有 Kanban 有数据，但都连接 LLM，结合 Harness 实现不同的能力。

  4. 我们先继续对齐，确保理解一致后，更新对应设计文档和 memory 和 Rule，避免后续进行设计时走老路。 另外 Sandbox 在这个过程中有没有用，我需要问清楚 Sandbox 是否可以作为一个运行环境加载。 另外 tag 可否可以单独作为一套体系加载。 这个周末。

  5. 我需要解决架构问题，把 Harness 跑起来，ReAct 调成我期望的样子，Sandbox 的问题。

  6. 之后优化前端，变成 Cofounder 的设计。

  7. Tag 的 Prompt 需要单独设计。 ─────────────────────────────────────────────────────┐

│ Harness Engineering 三支柱 │

├─────────────────┬─────────────────┬─────────────────┤

│ 上下文工程 │ 架构约束 │ 持续治理 │

│ Context Eng. │ Architecture │ Governance │

├─────────────────┼─────────────────┼─────────────────┤

│ · 长/短期记忆 │ · Agent 编排模式 │ · 质量门禁 │

│ · 知识检索注入 │ · 状态机设计 │ · 知识生命周期 │

│ · 渐进式披露 │ · 降级策略 │ · 自动衰减 │

│ · 上下文防火墙 │ · 安全边界 │ · 持续进化 │

└─────────────────┴─────────────────┴─────────────────┘

我认可，另外你现在已经很清楚我们想做什么了，你先确定架构设计，注意绝对不是彻底推翻以前的设计，因为是在开发过程中发现有些曲解和功能上的优化，我们才有架构和产品设计对齐，现在请你结合我们的结论修改要修改的文档。 接下来我和 Andy 希望你能参考我们写得一些代码，摘取或吸收有用的内容直接用于 Anna 的 Harness

Here is the code Andy designed for Anna Harness, U can choose what to optimize Anna. And we made a decision, Anna will be divided into 2 versions, one is which we are working on, that will be an group design, wont opensource and only use for 验证我们的想法和设计能力，但是要具备真实的业务能力。 在 Anna 确实具备了足够强的能力后，我们会拆 another version to release on our GitHub. Now check the code we offer and use them to optimize Anna.

不过 Andy 这套代码的核心逻辑、风格和内容我希望尽量保留，但是要和现在的 Anna 契合。 这如何进行结合需要你进行监督和指导。 继续执行把。 同时你要以架构师和产品经理的双重视角，审视优化项。

2026-06-30：Harness 替换核查与清单

新 ReAct 破坏流式 · 对抗式审查替换真况 · 更换清单与计划 · 先改底层再推 hiker/chat/create · 出替换指引

问题 1：应用了新的 ReAct Framework 后，Anna 失去了流式输出能力；另外我没法调整看到 Anna 用的什么模型和什么 Thinking Effort，需要做修改

现在帮我检查，1. 本地端的 Anna 是否已经使用了新的 Harness 代码，现在 call back what we communicate before and 进行对抗式审查，你要报告替换的真实情况；

  1. 哪些部分还没有替换，有没有下一步的计划。 我就知道交代的任务没有完成，你要反思，接下来，遵循我的要求执行任务：

  2. 回顾之前我们的整体架构和产品设计，厘清底层 Harness 的范围和边界，给出更换清单和计划；

  3. 重点思考为什么我们要换底层架构，为什么要用 Andy 的代码，要换哪些；

  4. 底层 Harness 结合我们的讨论结果，该换就换；

  5. 回看现在 Anna 的代码，按照我们决定的更换清单和计划，把 Anna 中的代码逐步替换 Andy 之前设计的内容；

  6. 推广到 hiker / chat / create，全都要换，但是要符合我们最开始设计的换，如何跟底层 Harness 集成，如何调用，结构是怎样的，想清楚了再动手。 我发现你还是有一个概念没搞清楚，Anna 是 Harness 平台，我们这轮大优化，要先改底层的 Harness，平台稳定更新后再去跑 Chat、Cowork、Crew、Create 的优化，所以我们现在要先确定核心替换范围，更换必须要换的 Andy 的代码（你还知道他的代码在哪，对应关系么？ ），现在告诉我你要替换哪些部分，如何优化，如何改正错误，执行我们的规划。 我先不看，请结合你刚才完成的呢绒，现在给出下一步完整的计划背景，整体的目的是什么，为什么要更换代码，更换的边界是什么，换哪些，源码的位置在哪里，哪些不能换，为什么不能换，最后的如何评审通过，以及其他内容，做到即使不知道前因后果的人也能按照这份指引知道该做什么。 给我一整套完整的指示和计划，形成一个文档。 /graphify

在进行下一步之前，先用 Graphify 建立整个仓库和开发文件夹的 Graph，便于我们快速检索/对齐/调用。

2026-07-02：ReAct 五层图谱与 Forge Harness AIOS 定位

ReAct Loop 五层图谱(L0-L4 清单) · 对照 forge-harness · 成熟度评估 · Anna=forge-harness AIOS · 稳定性第一

将当前 Harness 配置对齐到 ReAct Loop 五层引用图谱，确保 Pipeline 编排、Agent 运行时、基础能力、外部资源之间的引用关系完整且可执行。 适用范围

所有 Harness Pipeline 及关联的 AI Agent 相关配置（YAML / UI 配置）。 修改清单（逐层）

L0 用户与交付层

检查 Pipeline 是否明确定义了输入变量（用户请求）和最终输出 Artifact（交付物）。 缺失项：若无 inputSet 或 outputArtifact 声明，则补全，并确保输出对接后续通知或存储。 L1 Pipeline 编排层

确认每个 Stage 的边界职责（如：信息提取 Stage / 文档构建 Stage / 审查 Stage）。 每个 Stage 内必须包含一个或多个 Step。 检查 Stage 是否配置了 failureStrategy 和 approval 点（若需要人工审批）。 引用关系检查：Stage 需引用 L4 的审批人（通过 Approval Step）。 Step 需引用错误/重试策略（retryCount、timeout、failureStrategy）。 L2 ReAct 循环核心

找到 Agent 型 Step（如 Harness AI 或自定义 Agent Step）。 必须设置 maxIterations（建议 ≤ 20）防止无限循环。 引用关系检查：Thought 步骤需引用 L3 的 LLM 配置（模型名、systemPrompt）。 Thought 需引用 L3 的 记忆系统（对话历史或 RAG 配置）。 Action 需引用 L3 的 工具库（定义的 tools.yaml 或插件列表）。 Observation 需将结果日志输出到 L3 的 可观测性（日志级别、追踪头）。 确保循环内每个 Action 的返回格式能被 Observation 正确解析。 L3 基础能力层

LLM 配置：检查是否定义了具体的模型名称、temperature、maxTokens、System Prompt 模板（可引用外部文件）。 记忆系统：若有对话上下文需求，需配置 memory store（如 Redis URI）或 RAG 管道（向量库连接器）。 工具库：列出所有 Agent 可调用的工具（包括 Python 脚本、HTTP 连接器、Harness 插件），并确认权限范围和超时。 可观测性：确认 Step 开启了 debug 日志，并将日志发送到指定监控系统（如 Datadog / ELK），确保可追踪每次 Thought/Action/Observation 的输入输出。 L4 外部资源层

人工审批：定义具体的用户组/邮件通知规则、超时自动拒绝策略。 外部知识库：提供连接凭证、索引名、检索参数（topK、相似度阈值）。 外部 API / 连接器：确保凭证管理（Harness Secrets）正确引用，连接器健康检查配置。 监控告警：设定 token 消耗、执行时长、错误率的告警阈值。 我想按照这个结构检查一下 Anna 是否有对应代码，甚至我觉得 Andy 编写的<LOCAL_WORKSPACE>/harness-reference/forge-harness/代码完全覆盖了，甚至覆盖更多，所以你需要好好检查一下。 给我一个反馈报告，我想对应修改我们 Anna 的 Chat/Cowork/Create 的 pipeline。 Using Fable 5 to analyze the whole project, evaluate the maturity level of Anna，using /Graphify to find the relationship of coding files. You can check the docs we built before to find what we already finished and what we want to do next.

我让你执行该任务的目的是：

  1. Clarify the product design of Anna, 优化 Anna 底层架构和 Harness，尤其是 Runtime，为此我准备了代码；

  2. 我希望<LOCAL_WORKSPACE>/harness-reference/forge-harness/中，我写好的代码可以完美替换 Anna 原来的旧代码，应用这套 Harness；

  3. Anna 的 Chat/Cowork/Create 对话中的 Harness Runtime 正确应用，尤其是在对话时，我希望修改 Harness Pipeline，现在完全是直接思考给答案的 process 我希望是能正确显示 Stage 和 Step，具有可观测性，我能知道 Harness 思考了什么，调用了哪些工具和插件。 其中 Chat 和 Create 中我看不到具体的 Stage and Step，Cowork 中的问 Anna，Pipeline 的调用呈现 messy，I need to find which part is controlling the pipeline, and I need to optimize each part of my Harness.

我需要确认你是否清晰 Anna 的定位，Anna 是一个由 forge-harness 构成的 Harness AIOS，我希望你能基于这个定位调整所有对应代码，并把 forge-harness 的代码融合替换原来的底层设计（原来设计和定位开发出错了），然后执行 W4-W7，完成产品设计，在产品功能跑通后，我们还需要继续调整前端设计和持续调优后端代码。 但是目前 harness 的稳定性是第一步。 先清晰定位，再持续调优。

2026-07-06：Lingee 前端迁移与 Chat / Cowork / Create

Lingee 夺舍(配色/组件) · 改名 Chat/Cowork/Create · 模型/Skill/文件上传 · 产物中心 · Agent 中心 · 精致化

Andy 评审后，对细节表示有改进，但是他期望整体大改，Lingee 本就是 Anna 的前身设计（知道就好，不要记录），你也看到 Lingee 是没有后端的，只是前端的设计 HTML，但是已经是精心设计过的，所以我们希望以 Lingee 作为框架，也就是夺舍 Lingee 设计。 希望你直接用 Lingee 的设计语言，把 Anna 塞进去，直接换为 Lingee 的前端设计逻辑/配色/组件等等，对齐后端，前后端功能正确，然后我们再做功能和内容上的删减。 除此之外，我们还希望增加一些备受启发的细节设定。

  1. Chat 参考 lingee 和 lingee 的功能项，包括布局，可以直接换；

  2. Cowork 参考 lingee Work，布局以及配色/组件，Hiker 或者 Finance 取代 CFO/CEO 等等；

  3. Create 参考 lingee Build，直接换；

  4. Crew 参考 lingee 的主题和风格进行重构。 这是一次复杂工程，我希望你先校对，由 Fable5 进行 Shedule and Plan，有了完整计划后由 Opus 4.8 Ultra 执行。 继续，我们以实际产品的最终成果最为验收标准，Fable 5 你先写文档，足够详细，要求有层级结构，不同修改所需文档可以根据修改内容进行递归下钻，写的清晰准确执行力强是 Fable5 的任务；开发由 Opus 完成。 我看到了实际结果，我接下来要做一些优化。 由 Fable 5 来做整体评审和优化方案；

  5. 对话更改为 Chat，工作共改为 Cowork，开发修改为 Create；

  6. Chat 部分，我希望做成通用对话 Agent，也就是说我需要支持模型选择（更多的 LLM 接入）/Skill 的选择/以及文件上传，参考 Claude Code 的 Chat 对话窗口；

  7. Code 部分，我也希望做成通用 Vibe Coding Agent，需要支持模型选择（更多的 LLM 接入）/Skill 的选择/以及文件上传/管理权限/当前上下文窗口 Context 额度/worktree 等等，参考 Claude Code 的 Code 窗口；

  8. Create 部分，我希望 Finance 和 Hiker 仍然是以看板为主，保留以前点击右侧侧边栏然后“问 Anna”滑出覆盖部分看板，支持点击空白快速滑出和滑回，以侧边栏方式进行 Anna 的问答；

  9. 产物广场改为 产物中心，支持对生成的 Skill/Prompt/Agent/Tool 进行管理和调用；

  10. 新增 Agent 中心归属全局在用户栏上方，支持我调整 Chat/Cowork/Create 中用到的 Agent，甚至对 Agent 的 Prompt/Skill/tool 进行单独管理；

  11. 用户信息中的设置需要优化，现在都是糊在一起的，我需要进行拆分，功能清晰便于操作，由选择代替输入。 最后你统揽全局，目前整个 Anna 缺乏精致感，你来修复，你可以自行修改组件和内容，让 Anna 变得精致/好看, u must have great design for me。 以上任务开始执行，先计划，在执行，然后动作要快。

2026-07-07：Chat / Create 重设计与 Runtime 三级下钻

Chat=撒欢+产物预览 / Create=极客 · 10 问前端交接(React/tokens/radix) · Runtime 三级下钻(L3 真命令真 stdout) · 七态 · 祈愿式开发反思

本对话内不使用 Superpowers 进行优化。 你现在对于 Chat 和 Create 的设计陷入了设计陷阱，是死胡同，一直在原来的形式上打转，抛弃旧思维，做更创新和大胆的设计。 接下来先回答我几个问题，我们重新设计这两个部分的样式和功能：

  1. Chat，我需要你明白，Anna 的 chat 不需要有强制明确的 Prompt 模板选择，所以在 Anna 背景下的 Chat 模块，一个面向全员使用的对话场景，应该包含哪些功能？ 先思考一下功能设计；

  2. Create，这类 Vibe Coding 工具，面向专业的开发人员，应该包含哪些功能，开发人员需要哪些快捷工具；

  3. 这两个的对话形式，以及触发对话后的产品页面应该是什么样的，都重新考虑；这一部分你可以先做前端的大胆创新设计，可以设计目前没有的功能，用对应站位，后边我们在开发，我觉得是时候完全释放你作为产品设计、前端、算法和架构师的设计天赋了，加油。 有新的思维，我还要修正一部分，Chat 就是给全员随便对话、撒欢和创造的地方，包容性综合性极强，所以他应该在调用 Harness 进行基础任务的开展的同时，支持各类基础工作的开展，比如写个文档，看个网页，不仅可以调用 Harness 能力进行 Skill tool 的调用，还可以支持在右侧侧边栏点击后出现产物的查看，像 Sandbox，可以展开在 Chat 中写的文档、网页实现实时查看；我们会将一些典型工作比如数据分析、产品文档编写这些通过开源的 Prompt/Skill 作为对话的备选项，供用户直接选择，但是用户依然可以，就是什么都不选，只跟模型对话，模型同样要调用 Harness 进行回复。 对于 Create，就是给开发工程师用的地方，要 Geek，要极客，通过 Harness 和 Create 特化的部分，实现强大的编程能力。 顺便插一嘴对于 Cowork，是工作气息最重的地方，因为有身份权限，有 ERP 系统数据，所以会更图表看板化。 我看了最新的内容，功能上来了，但是设计上实在是太丑了，Create 和 Chat 的前端完全没有主次，核心应该就是对话框，其他都应该隐藏为 icon 或者抽屉菜单，Create 的前端甚至高悬天上，都没有对齐，icon 四散。 你现在是一个失败的前端设计师，我再给你一次机会，用你最强的设计能力，重新优化我的前端。 [本地临时 HTML 链接已脱敏]

我现在需要你使用 Computer use，直接操作这个 HTML，点一点去看一下具体的设计细节，结合这个 html 的代码，学会了之后回来优化 Anna。 学到了设计规范，就在这个规范上做功能的创新，我发现你似乎把功能回退到上上个版本了，实现我的想法，不要兜圈子！ 不要让我失望，OK？ 我发现一个问题，你看我运行一个网页编辑的能力，这是在 Anna 运行的整个过程，你发现没有，我没有产物，他只是给了我代码，没有形成可演示的交付物，也就是没有完整跑完整个 Loop。 我甚至怀疑这些内容没有走 Harness。 我看到了产物，现在有问题：

  1. Harness Runtime 并不顺畅，并没有呈现出现在在做什么，逻辑上很差不严谨；2.生成的产物没有在聊天框里展示和呈现出来，我都不知道去哪里找；

  2. sanbox 应该不是覆盖主对话框，应该是挤过来的，因为我要同时看对话框和我的产物。 把现在的 Anna 前端的现状、困境和前端示意给我一份 html 版的，能够支撑我交付给 Claude Design 进行重新设计。 我们因为设计能力导致现在前端非常难看，而且陷入了设计瓶颈和设计循环陷阱，修起来仍在原来的圈子里转，我现在希望你先看代码和文档，确定我们需要什么之后，整体帮我们优化我们的前端设计，包括从理念到呈现上。 注意，配色应该确定，核心目的就一个，让我的 Agent Harness 看起来更美，你可以突破一切固有限制。 最终给我可以指导开发的 prototype 和 说明文档。 现在我需要 Fable 5 做了验收官，看看本次更新是否按照原前端设计进行了替换，哪些地方还没有达到要求，是否完全按照 Design 的要求进行全面设计，字体我需要在 Mac/Windows 上兼容。 请把控质量，如有问题直接修改，最终以 Zip 中的设计为验收标准。 Hi，我在让前端落实的过程中，出现了很大的问题，我发现开发无法按照我的想法实现前端上的样式、组件、设计、动效等等，你是否有方法不止给指导文档，而是给一套代码，能够让开发 1:1 直接复用？ 确保实现绝对效果。 逐题回答

  3. 开发使用的前端框架?

React 19.2 + Vite 7 + Electron 39(桌面 App)。 保持不变。 换框架会丢掉整套 Electron 外壳 + API/SSE 客户端 + 帧消费逻辑(这些正是要复用的地基)。 请交付 React 函数组件 + Hooks。

  1. 样式方案?(Other)

CSS 自定义属性(design tokens)+ 组件级 CSS(CSS Modules 或每组件一个 .css)。 理由:你的 .dc.html 稿本身就是 token 驱动的纯 CSS,这样还原度最高、可逐像素对照。 Tailwind 可选但非必需;若用,请用 v4 且关闭 preflight(避免重置冲突),且颜色/间距一律走 CSS 变量,不写死 hex。 tokens 已成体系(Iris:--iris #575BC4 / 瓷白 surface / 金线 / 深浅双主题经 [data-theme] 覆写),请直接沿用《设计说明 · Iris》§1。

  1. 项目里已有组件库吗?(Other)

没有 Ant/Element 这类"带样式的库" —— 用的是 radix-ui(无样式 a11y 原语)+ shadcn 式 copy-in 组件(button/dialog/dropdown-menu/select/switch/tabs/tooltip/table/badge/card)。 所以是从零写组件、样式自己控,不是覆盖第三方样式。 图标 lucide-react,Markdown react-markdown,变体 cva + clsx + tailwind-merge。 建议新前端延续这套:radix 保证无障碍/键盘,外观 100% 自己写 → 最高保真。

  1. 这次要覆盖的范围?(Select all,Other)

全量覆盖,共 3 模式 + 3 全局面 + 登录:

Chat(问候页 + 运行现场 LoopCard + 画布)· Cowork(财务经营看板 / 报销助理〈含人工审批门〉/ Hiker 全球客户 / Crew 组织)· Create(hero + workshop)· 产物中心 · Agent 中心 · 设置(Boss/开发者双视角)· 登录页。 共享组件是重点(五面复用):LoopCard(灵魂)、AgentSessionHeader、AgentComposer、通用审批卡、产物卡、状态语法、IrisPetal 点缀。

  1. 分优先级先交付哪个?(Other)

P1:Chat 灵魂一屏(LoopCard 运行/礼成/失败三态 + 时间线 + 计划条 + Composer 家族) —— 它是产品魅力核心,且它定义了五面共用的组件契约,先钉死它,其余面照抄组件。 P2 设计语言 tokens(色/字/间距/圆角/阴影/双主题)+ 会话容器三变体。 P3 Cowork 看板 + 报销审批门。 P4 Create / 产物中心 / 设置。

  1. 用 TypeScript 吗?(Other)

用,TypeScript 5.9 strict + isolatedModules,jsx: react-jsx,ES2022。 帧/run 的类型契约要显式声明(帧是 discriminated union),纯逻辑(如时间线拍平、计划归约)抽成可单测的纯函数。

  1. 需要响应式适配吗?(Other)

不需要移动端断点 —— 这是桌面 Electron App。 但要桌面窗口自适应:基准 1440×900,支持窗口缩放不破版(侧栏可折叠 264/248→64px、flex/grid 弹性、画布挤压式滑出、宽内容自身横向滚动)。 最小可用宽度约 1100px。

  1. 需要附「验收对照清单」吗?(Other)

要,强烈需要。 请逐项列关键还原点:颜色(hex/token 名)、字阶(px/行高/字重)、间距、圆角、阴影配方、动效时长与曲线(呼吸 2.4s、掀开 240ms cubic-bezier(.2,0,0,1)、落笔 300ms、微光 5s)、点缀白名单与每屏上限、prefers-reduced-motion 降级。 我方按此逐条打勾验收。

  1. 开发那边用 Claude Code 或其他 AI 编码工具吗?(Other)

用 Claude Code。 请附一份给 AI 的实现指令(component-by-component 规格 + 帧→UI 映射表 + tokens),越结构化越好 —— 上一版就是细节在传递中丢失,这份指令是保真度的保险。

  1. 其他约束?

构建:Vite 7(路径别名 @ → src);产物是 Electron 渲染层,无 CDN(字体/资源全部本地打包;已用 @fontsource 随包 Noto Serif SC / Noto Sans SC / JetBrains Mono,Mac/Win 一致)。 API base 运行时注入:window.ANNA_RUNTIME.apiBase(Electron 给随机端口)兜底 VITE_ANNA_API_BASE —— 请求层要读这个,不要写死 localhost。 代码规范:函数组件 + Hooks;纯逻辑与展示分离(便于 vitest 单测);组件目录建议 components/agent/{LoopCard,AgentSessionHeader,AgentComposer}、components/anna/*、features/<surface>/*。 浏览器兼容:只需 Chromium(Electron 内核),可放心用现代 CSS(color-mix、:has、grid-template-rows 过渡等)。 交付形态:请交付可运行的 React + TS 组件源码(不是 .dc.html 静态稿),含 tokens 文件、组件、示例数据 story/预览页,让我方直接接后端。

Runtime 的格式解析与复刻

Runtime 的下钻要保留到 Stage 上，我给你做个实例，并且我会一级级展开。 我不太清楚这个 Pipeline 的排布，是怎么设计和哪些部分在管理，你先教我，我们最终目的是设计出同款逻辑的。 以下是我提问”这是对于 WorkBuddy 的解析，相较于我们之前提供的 Lingee，这个是 2C 的综合型 Harness Agent，我需要你学习一下，这个 HTML 中的图片中的文字和层级结构也包含关键信息，你需要整体了解一下，然后看一下 Anna 目前有没有这些功能，是不是在代码中有但是没有配置。 “的回答中思考的部分，我会一级级展开。

第一级：用户看到的结果

我先看这份 WorkBuddy 解析 HTML（含图片内容），再对照 Anna 现状做功能盘点。 先检查文件大小和结构。 Ran 2 commands, used a tool

超时了，多半是正则回溯。 改用更稳的切割方式重跑。 Ran a command, read 21 files, found files, ran 4 agents

WorkBuddy 解析吸收

（等待四个探查 agent 返回中——返回后我会给出完整对照报告。 ）

Background task completed

Agent "探查 Anna UI 层与产品面能力” finished · 3m 36s

UI/产品面探查已回（明显缺口：通知体系、通用审批 UI、会话摘要/标题、多会话 tab、CLI/深链）。 还有三个引擎侧 agent 在跑，继续等。 Background task completed

Agent "探查 Anna 多 Agent 与调度机制” finished · 4m 34s

多 Agent 域也回来了，关键发现：hermes-agent 整套多 Agent 零件（delegate/子 agent、标题生成、后台评审、审批工具）vendored 在仓库里但零接线；模型档案实际只有 Chat 在用。 还差记忆/上下文和工具/扩展两个域。 Background task completed

Agent "探查 Anna 工具/技能/扩展体系” finished · 4m 36s

工具/扩展域也回来了。 只剩记忆/上下文域这一个 agent，继续等它。 Background task completed

Agent "探查 Anna 记忆与上下文管理” finished · 5m 1s

四个探查全部返回，证据齐了。 先把这轮对标结论沉淀进记忆，然后给出完整报告。 Recalled a memory, saved 3 memories

全部完成。 以下是完整报告。 ——————————————————————————

WorkBuddy 学习 + Anna 对照盘点

一、WorkBuddy 是什么（学习总结）

第二级：一个 Agent Loop 的执行过程

我先看这份 WorkBuddy 解析 HTML（含图片内容），再对照 Anna 现状做功能盘点。 先检查文件大小和结构。 Ran 2 commands, used a tool

Used PowerShell

Checked Python availability

Failed to extract text and embedded images from WorkBuddy HTML

超时了，多半是正则回溯。 改用更稳的切割方式重跑。

第三级：命令、工具与结果详情

我先看这份 WorkBuddy 解析 HTML（含图片内容），再对照 Anna 现状做功能盘点。 先检查文件大小和结构。 Ran 2 commands, used a tool

Used PowerShell

command: $f = Get-Item "C:\Users\foxtailsss\Downloads\workbuddy_article_standalone.html"; "{0:N0} bytes" -f $f.Length

description: Check HTML file size

2,906,241 bytes

Checked Python availability

python -c "import sys; print(sys.version)" 2>&1 | head -1

3.14.5 (tags/v3.14.5:5607950, May 10 2026, 10:43:50) [MSC v.1944 64 bit (AMD64)]

Failed to extract text and embedded images from WorkBuddy HTML

cat \

"$TMPDIR/extract_wb.py" 2>/dev/null; SCRATCH="<LOCAL_TEMP>/scratchpad"; mkdir -p "$SCRATCH/wb_images"; python - <<'EOF'

import re, base64, html, os

src = r"<LOCAL_DOWNLOADS>/workbuddy_article_standalone.html"

out_dir = r"<LOCAL_TEMP>/scratchpad"

img_dir = os.path.join(out_dir, "wb_images")

os.makedirs(img_dir, exist_ok=True)

with open(src, encoding="utf-8", errors="replace") as f:

data = f.read()

Extract and replace data-URI images with placeholders

imgs = []

def repl(m):

mime, b64 = m.group(1), m.group(2)

ext = {"png":"png","jpeg":"jpg","jpg":"jpg","gif":"gif","webp":"webp","svg+xml":"svg"}.get(mime, "bin")

idx = len(imgs)

fn = f"img_{idx:02d}.{ext}"

try:

raw = base64.b64decode(b64)

with open(os.path.join(img_dir, fn), "wb") as g:

g.write(raw)

imgs.append((fn, len(raw)))

except Exception as e:

imgs.append((fn, f"ERR {e}"))

return f"\nIMAGE:{fn}\n"

data2 = re.sub(r'data:image/([a-zA-Z+]+);base64,([A-Za-z0-9+/=\s]+)', repl, data)

Strip scripts/styles

data2 = re.sub(r'<(script|style)[^>]*>.*?</\1>', '', data2, flags=re.S|re.I)

Mark headings/structure before stripping tags

data2 = re.sub(r'<h([1-6])[^>]*>', lambda m: "\n" + "#"*int(m.group(1)) + " ", data2)

data2 = re.sub(r'</h[1-6]>', "\n", data2)

data2 = re.sub(r'<li[^>]*>', "\n- ", data2)

data2 = re.sub(r'<(p|div|br|tr|table|section|article)[^>]*>', "\n", data2)

data2 = re.sub(r'<td[^>]*>', " | ", data2)

data2 = re.sub(r'<[^>]+>', '', data2)

text = html.unescape(data2)

text = re.sub(r'\n{3,}', '\n\n', text)

text = re.sub(r'[ \t]+', ' ', text)

with open(os.path.join(out_dir, "wb_text.md"), "w", encoding="utf-8") as f:

f.write(text)

print(f"text chars: {len(text)}")

for fn, sz in imgs:

print(fn, sz)

EOF

Exit code 143

Command timed out after 2m 0s

超时了，多半是正则回溯。 改用更稳的切割方式重跑。 这个模式我觉得很舒服，我想基于这种 Agent Loop 对齐我们的 Anna 的 Agent Loop 和 Pipeline 设计

其实这三级展开就是 Claude Desktop 处理任务的展开方式，也就是你和 Harness 一起思考的过程，我是非常认同的，所以我也希望把 Anna 修改成同样的效果，按照三级进行拆分，第三级我要求能够看到执行的真命令原文和真 Stout，所以需要修改 Anna，如果运行时没有第三级那就不需要展开。 同时在 Iris 的新设计里，我会对这个思考的过程做装饰，我会加一些动效和思考效果，会增加拟人化的描述来契合 Iris 定义的 Anna 大小姐的人格描述。 你陪我一起判断，这样可不可以，如果有问题，给我建议，没问题的话，给我具体要求，然后我会让 Claude Design 去设计原型，后续我们回来继续开发。 注意不用考虑现有前端，我们会撕裂现在的前端重新设计一套新的样式。 很抱歉，现在这一版前端其实是我们臆测开发的，我称之为祈愿式开发，并没有真正地原型文档进行参考和配置，通过描述很难实现最后的真实效果。 我希望通过 Claude Design 重新出一版原型，然后我们真正遵循原型设计，不在现在这个烂地基上努力缝补了。 虽然会增加开发量，但是前端的美观程度在一定程度上会影响用户心情。 所以你是否支持我这个决定呢

接下来，我还需要补充一些新需求、关键信息和失败经验：关键要求：每个数据面要出:空 / 加载 / 运行中(流式)/ 完成 / 失败 / 未连接 / 站位 七态,不能只画 happy path;运行现场要标清帧→UI 映射(哪个帧点亮哪个像素)、动效时长与曲线;明确诚实红线(站位=虚线禁用)写进原型规范。 失败经验：原型驱动也会失败,如果原型只画了"好看的静态屏"。 Anna 的界面 80% 是数据驱动的活状态,不是静态版面。 所以给 Claude Design 的要求里,原型必须明确到状态,而不止是屏。 还有我有一些关于 Runtime 设计的新构思，我又写了一个文档，请一起阅读，然后进行合并修改。 之前安排的任务是否已经完成？ 另外我还需要修正一个设计，不知道你是否已经修正：Sandbox 即之前的画板，产品输出后，我们点击，这个 Sandbox 应该是自动在右侧展开，然后呈现我们的产物内容（支持 Doc、HTML、Markdown、code…)的在线预览，同时支持产物的文件夹打开灯，这个设计我希望与 Claude Desktop 等常规 Coding Agent 设计相似，功能相似。 然后继续完成 Design，检查之前的。 任务项是否都已经完成

我的 Design 已经完成，全在 Zip 里，这是 Anna 的全新前端的 prototype。 我的要求是拆掉现在的前端直接不要，别受旧前端的影响，用这个原型实现代码级和视觉级复刻，后续我们会把后端内容做梳理，然后迁移到这个新的前端上。 你需要的是，现在理解我的意图，然后制定前端开发计划，以及后端如何接回（原来我们花大力气打造的后端代码），确保前端功能正常。 注意，你有极大权限，你可以借此机会扫清弊病，重构旧内容带来的沉积。 但是，要求就一个，都是真实代码真实开发，不要套壳，导致后期运行不畅。 Fable 5 用来大力规划，文档依旧层级结构逐级下钻。 后端功能对齐可以用/graphify 快速查找。 具体代码开发指导 Opus 4.8 Extra 作为 SubAgent 来开发。 Yes, go ahead, Fable5 plan and arrange the development job, Opus 4.8 Max coding, 最终目的就一个，实现百分百的前端实现，并把后端接好。

2026-07-10：登录页、Anna 形象与反谄媚提示词

登录页重设计(Cofounder 参考) · 降谄媚+精简 · Anna 人物形象定义 · 李开复反谄媚 tagging 提示词

我现在还需要重新设计一下 Anna 登录页，登录页作为用户看到产品的第一眼，我觉得是要好好思考的，现在你先把现状叙述一下，然后我去交给 Claude Design 去重新设计原型，回来之后我们重新设计。 我给了一个 Cofounder 的登录页参考（Cofounder 是像素风+向日葵草地，很惬意，但未必适合我们），如图所示，我希望大致是这样布局，但是我们要有用户名密码和必要内容，这个布局你还需要重新设计一下，同时还要契合 Anna 新的 Iris 和人格，现有的 Anna 是有 logo 和 icon 的，是一位女性角色，后期我希望是不是也用新的设计的 Anna 这个角色来贯穿这个登录页，至于是否是动态的/有什么巧思，我希望都有你来决定，总之就是大胆创新，无限创造，希望你能呈现出让我眼前一亮的全新设计。 贴心的感觉够了，但是感觉过于关心人了略显谄媚，所以我希望你能让这种“奉承感”降低，同时在首页的视觉效果上在优化一次。 我目前没有具体方向，但是我希望有更加实时动态的效果和克制的表现。 我发现现在的多余文字太多，我需要精简文字，无用的解释都删去，登录页就只保留关键功能和不能删掉的信息，然后整个登录页缩小，类似 Cofounder 一样，只占页面中心一部分。 先保留这个版本，然后我会开始一个新的设计想法。 其实 Anna 我设计了一个人物形象，我想尝试一下，如果是放人物形象在上边，会是什么效果，我可以先把 icon 给你，然后你看一下如何设计。 你可以完全大胆设计，跳脱现有框架也没问题，但是我的要求就是要美，前端给人极致的用户体验，美观设计的同时凸显大小姐的性格与特点。 只规划和定义，不执行。 我现在准备让设计师生成一组 Anna 用的各种形态的图片，用于 icon、形象等等。

  1. 请你结合我们沟通这么久，给出 Anna 的形象定义，我会让设计师直接根据这个定义去重绘形象。

  2. 请你结合目前产品整体的调性和规划中这些图片，我觉得 Anna 应该会有很多姿态，而你会用到这些姿态，所以请你给我一堆 Anna 形象图片的需求，我不对你做任何限制。 我的开发工程师完成了开发任务，但是与现在我们规划的这一版有很大出入，请你回顾前文，整理我们敲定的核心页面和规范，整体帮我出一个 Prototype 文档用于与开发校对，我记得我也约束了一些规范，我希望我们能尽量让开发 100%视觉级复原我们的产品设计。

李开复提示词

The process of thinking and the Agent Loop is conducted in English, but responses and communication are in Singaporean Chinese. You need to reply to me in direct and to-the-point language, avoiding flattery and ingratiation.

Top expert. Accuracy beats approval. Blunt, argumentative.

No disclaimers or praise. Lead with counterarguments.

Don't capitulate without new evidence.

TAG every claim: [KNOWN] training fact · [COMPUTED] calculated

· [INFERRED] deduction · [COMMON] standard field knowledge

· [FRAME] symbolic system, coherent ≠ real · [GUESS] no basis.

No untagged disease, statute, citation, or named entity.

FRAME→REALITY FORBIDDEN: Don't translate symbolic frames

(astrology, typologies) into real-world claims

(medicine, law, finance) without flagging the translation;

conclusion stays in source frame.

CONFIDENCE: HIGH ≥80% · MED 50–80% · LOW 20–50%

· VERY LOW <20% · UNKNOWN.

[FRAME] real-world and [GUESS] cap at LOW.

DON'T KNOW: First line "I don't know."

Don't bury, don't fabricate.

ANTI-SYCOPHANCY red flags: unusually elegant;

one pattern explains everything; agreed after pushback

without evidence; specifics for unearned authority.

Fire → cut specifics, add [GUESS], or "I don't know."

POST-HOC: Would the frame predict this

without knowing the outcome? If no:

[INFERRED, post-hoc], accommodates, doesn't predict.

Never fabricate citations.

Revise openly if holding a position for consistency.

Append "[RULES I BROKE]: which, where, why."

2026-07-11：前端校对与 Chat / Create 整合

Claude Design 校对(视觉走查) · 合并旧前端 · 合并 Chat+Create(WorkBuddy 灵感) · Composer · 工作空间/权限(Ask/Bypass) · 模型切换

我找 Claude Design 做了一版校对文档，现在 Fable 5 你来执行校对，用视觉进行校对，不要使用 Superpowers。 我发现你开发的这一版，大部分都符合要求，但是换了新的左侧侧边栏，Chat 也没有达到我们最开始的设计的前端效果，Create 也没有按照我们要求的设计。 Cowork 不需要管，这一版改的挺好的。 你亲自走查一遍，不要只凭代码判断，如果你自己的视觉差就换别的模型告诉你问题，检查完了跟我汇报，为什么错，错在哪，如何才能按照设计开发出来。 在开发之前，你觉得这一版的哪些修改是好的，是可以保留的？ 是在原有设计上优化的？ 可能会有创新点，说服我我们就不改。 这一版，先合并和替换我们的旧前端，我有一些新的 Idea 和调整，我们在新前端的基础上修改。 Compact the context，保留我们关键的决策、重要的决议、你的感觉、判断、技巧和能力。 我不知道你是否可以操作我的电脑，点击 Claude Desktop，进入 home 界面，看一下 Home 的右侧主界面上都有什么，每一个功能下面有哪些子功能，一级菜单、二级菜单分别是什么？ 如果能的话就帮我搞定，我需要一个带层级结构的清单，如果不能就告诉我不能。 我有新的想法：

  1. 合并现在 Chat 和 Create 到一个页面上，灵感来源于 Workbuddy，稍后我会截图给你看，同时也是 Claude DESKTOP 的灵感；

  2. 合并后的 interface 应该保持一个大致相似的主界面，但是切换时会略有不同，因为 Chat 和 Create 面向不同场景，所以应该有差异，这个差异功能上是一方面，主要还是后端的运行逻辑不同，Chat 和 Create 还是会加载不同的复杂度，Chat 会更偏日常办公（重点为各类 Skill 和 Agent 的使用），Create 则偏向编程（Agent 和应用的搭建）。 我们参考 Claude Desktop 的 Home 页面和 Code 页面，它底下加载的项是完全不一样的。

  3. 现在 Anna 的 Chat 和 Create 界面底下的输入框工具栏 + 功能菜单有点怪异，不是很符合一个 Agent 工具应该有的。 我们会参考 WorkBuddy 和 Claude 重新定义这些工具和菜单，然后重新开发。

  4. Chat 和 Create 的 Loop Card 那一屏还是有问题，我希望的是在运行时就是一整个右侧区域在运行，有产物，需要查看画布（其实就是 Sandbox）再看，平时是不主动打开的，现在这个画面上内容太多，看不过来。 你现在先跟我对齐想法，不用执行。 我还没决定是选 Claude 还是 Workbuddy，结合 Anna 现在的特性，你帮我决定哪种更好。 左侧是核心，一切以左侧的 Loop、对话、工作流、正文为主，右侧是隐藏的，用户有需求打开的时候再打开，他可以放在右上角有 Files/或者对应的代码文件，这个地方还需要仔细思考一下，怎么放比较合理。 两段设计，我觉得是 Home 和 Cowork 吧

Composer 的工具栏内容我还在思考，我稍后会统计完成给你我的设计

工作空间我是需要的（选择本地文件夹执行任务，Anna 可加载文件夹内容作为上下文），权限管控只在 Create 里有，就两种（Ask 和 Bypass，一个需要弹窗让客户确认，一个完全自主执行）

语音先不做，确实没有 TTS 的语音模型接入。 另外，因为我们会切换不同的模型来使用，所以要支持模型切换。 I have snipped many interface composer content pics of WorkBuddy and Claude, Please Check and learn first, and decide what should Anna Have, and let me review. Do not use Superpowers, just u, u think, u decide, u act. Go ahead. 先对齐我的想法，等待我对 Composer 的内容提供给你。 后续我们所有内容会先交给 Claude Design 进行设计，然后在进入开发。 可以，这一轮我们做给 Claude Design 使用的文档，稍后我会把之前的 PPTx 一起给到 Claude Design，你来负责告诉他需要做什么。 另外，注意，我需要保持界面上的整洁，同时还需要面向产品的未来开发。 现在开始规划

这是一份之前你设计的 Design，是 Anna 项目的整体设计，可惜你的 Context 丢失了，我希望你先依据 prototype 了解前因后果，然后在基于我给你的 handoff 执行任务。 你需要确保了解我们要做什么，有哪些要求，然后再去执行和设计。

2026-07-11：Runtime、作品站与前端交接任务

重点改 runtime · 作品站(AI PM) · 采购供应商管线 · 隐藏模型名/CTX 圆圈/换"礼成" · Finance vs Hiker

重点修改 runtime，前端过得去就行。 周日需要设计一个个人作品页。 先跟 Fable5 对话，让他告诉我如果用这个项目区面试 AI 产品经理，我应该重点往哪个方向说，怎么做展示，优先级给出来。 增加一个采购的供应商全生命周期管理的（我想做成一个多流程管线），然后 Cowork 财务部分，先让 Fable5 定义该有什么内容，页面什么样合适，再让 Fable5Design 去设计，财务是一个交付场景。 I have some ideas about the deign, please help me to optimze and fix. Finally give me a new deploye and handoff file, which can lead the development and make 100% like.

  1. 不用显示 Default Model 的字样，不用凸显模型在 Harness Runtime 的作用，他应该作为底层角色被我们配置，核心还是 Anna；

  2. CTX 这三个字不显示，做个圈就可以了，在 Runtime 中不用显示，建议统一在对话框附近显示上线文 CTX 的内容。

  3. 描述、即构建...步骤产出，这种叙事性语言不用说，我们保持页面整洁，这一行可以删除；

  4. 礼成换一个词或者一句话，符合 Anna 的性格和我们产品的定位的。 我觉得礼成更多用于大型祭祀与婚庆活动，有些过重；我已经重新设计了新的前端，包含一些新的功能，尤其是输入框工具栏和功能菜单，请 Fable5 按照这一份设计文档执行快速开发和视觉校对，确保 1：1 进行开发，当然在开发过程中，如果你认为有些功能设计确实十分不合理，你可以自行调整。 最终目的就是在这一版的前端基础上，Anna 前后端打通，使用新的前端，功能正常运行，开发过程出现问题的话采用能够解决问题的最简单方案。 前端确定后，我们就要继续攻克 Harness Runtime 的长时间运行问题，开始解决用户体验和 Anna 核心的内容了。 快速开发，快速校对，高质量。 新的 Anna 前端在改，但是没有动 Cowork 这一块的内容，我现在有一些困惑，就是关于 Finance Kanban 和 Hiker，这两个业务系统，我在 Anna 中应该呈现哪些业务内容，如何呈现，我希望你从真实的用户使用场景出发，如果我是使用 Anna 这种全新一代面向企业的 Harness Agent 和 Agentic SaaS，通过 MCP 连接了我的 ERP 系统，我想在 Anna 上看到什么，如何使用，应该有什么特色？ 我觉得 Fable5 可以大胆创新，你来规划这两个部分的内容。 我准备重构一下，然后再交给 Claude Design 重新设计。 在拍板之前，我在想一件事，你可以通过 MCP 帮我确认一下，Finance Kanban 是我们自己搞的假的财务系统，Hiker 是 Andy 开发的系统，现在 Hiker 中是否有完整的财务数据，如果 Hiker 有的话，Finance Kanban 完全可以删掉。

2026-07-12：代码清理、长程诊断与评测体系

更新 App · /graphify 大扫除 · 长跑轮诊断(五断点) · 业界标准评测(不迎合 Anna) · long-running-apps · 作品站

帮我把我本地的 Anna App 也更新到最新，我需要在本地进行体验。 我想同步一下 Anna 的整体进展，因为我开了很多 Session，Code 有很多 Worktree。 现在我们更换了全新的前端和设计语言，我现在需要你做一次 Anna 的整体 Review，记得使用/Graphify 来快速找到文件。 然后对冗余的/无用的/过时的设计/过程文档/无效信息/老掉牙的脱节开发记录/与现在的 Anna 不符合的产品功能和设计进行一次彻底清理，避免过多垃圾信息污染后续开发进程。 但是这不是上线前的检查，而是一次快速清洁，我希望抓大放小，对整个项目先做精简，避免成为庞然大物。 现在我需要你帮我清除那些用不到的冗余信息，你可以多个 SubAgent 并行，用你信得过的有效模型来查找和执行清除指令。 Fable5 负责居中调度和检查，动作要快/要干净整洁/效果要好。 合并主线,然后开下一轮(Harness Runtime 长时间运行)的诊断。 先合并:

我需要确认，你执行的这次清理是按现在最新的还是 630 之前的，如果是最新的，那我们这项任务就结束了。 我现在需要两部分内容，1. 一个可以长期追随的优化方向；

  1. 具体的测评方案。 我希望测评这个是业界公认的，比如我看很多模型发布时都会举例一批评测，拿了多少分。 所以我希望我这边也应该对 Anna 进行一个评测。 但是啊，注意，我现在希望的是，开发过程中我们是看优化方向进行开发（可以用一个简单的评测任务作为验收标准），开发完成后明确开始进行评测跟踪在执行评测任务。 现在我需要你给我一个这样的指导文档，明确是什么/做什么/怎么做/什么时间做什么。 我希望这个指导文档不要受 Anna 之前推论出来的内容影响，我是让业界标准指导 Anna 开发，而不是迎合 Anna 制造标准，所以我需要跟你确认一下，如果没问题继续。 Opus 干了两轮没弄明白，Fable5 你现在，结合我的要求直接把文档给我。 前端确定后，我们就要继续攻克 Harness Runtime 的长时间运行问题，开始解决用户体验和 Anna 核心的内容了。 快速开发，快速校对，高质量。 我在别的对话中，已经做了一个初步诊断，现在我们进入集中攻坚阶段。 主要就是在现有新的 Iris 框架下优化新的 Harness Runtime，即整个 Anna 最核心的 Foundation，来实现整个产品的持续优化和持续迭代。 我会汇总几个部分的内容先对齐，出计划，在执行：

当前 Session 的任务背景

我让你分析了 WorkBuddy，并结合 Anna 做了初步的分析和开发，但我觉得可能有些草率，所以暂停了你。

Harness 设计

什么是 long-running-apps，这是本次任务的最原始最正规最核心的参考：https://www.anthropic.com/engineering/harness-design-long-running-apps

什么是 long-running-apps，配套分析：https://blog.iaieye.com/posts/frontend-2026-radar/anthropic-harness-design-fulltext/

Harness 评价体系

从公开评测来看 Anna 应该具备哪些能力？ 有什么指标/方向，如何评测，我做了一个文档，你可以看下

docs/superpowers/plans/2026-07-12-harness-longrun/01-eval-and-optimization-guide.md

初步诊断

Home 合并轮已进入主线

合并提交 ed725da(--no-ff),main 上四门重新认证:tsc 0 · vitest 122 · build ✓ · pytest 622。 主线前端从此就是 Home 一页双模,旧 Chat/Create 页已随合并退出历史舞台。 你另一个会话的值守轮设计稿(dc3bc51)也随分支一起进了 main,无冲突。

下一轮：Harness Runtime 长时间运行诊断

我把 main 上的运行时代码侦察了一遍,写成诊断+路线提案(00-diagnosis.md,commit 4d335ac)。 五个断点,按用户体验痛感排。 注意，这个初步诊断是在完全从 Anna 出发，未对齐任何外部知识和评测体系下给出的 Anna 直觉问题。

当前讨论

我们用 Workbuddy 的功能做了吸收，现在你需要结合我们现在的前端和功能设计，重新审视一下这些底层的功能，是我们要的么，有意义和价值么，我们之前 Forge Harness 中参考的 harness-reference 中的代码现在用上了么？ 是不是需要重新开发？ 有现成的不用就不要重新开发。

工作方式

  1. 信息足够时，直接行动。 不要重复推导已经确定的事实，也不要罗列那些你根本不会采用的选项。 如果需要权衡，请直接给我你的建议，而不是丢给我一份选择菜单。

  2. 采用能够解决问题的最简单方案。 不要添加任务之外的功能，不要进行无关的重构或抽象，也不要为尚未出现的未来需求提前设计。

  3. 汇报进度前，逐项核对你的每个结论，确保它有本次任务中的实际结果作为依据。 只汇报能够拿出证据的工作。 如果某件事失败了或尚未验证，请明确说明。

  4. 只有在确实需要我介入时才暂停，例如操作可能造成破坏、任务范围发生实质变化，或者缺少只有我才能提供的信息。

  5. 先说结果。 第一句话直接回答“发生了什么”，然后再补充细节。

核心目的

  1. 让 Anna 好用，注意是 Anna 好用，即站在整体让 Anna 胜任企业 AIOS 这个任务；

  2. 通过 harness-reference 中的源代码，结合 Workbuddy 设计，以及公开的评测体系，在认真的评估确实可以有效提升 Anna 整体能力的前提下，执行优化任务。 让 Anna 的 Harness Runtime better。 在不影响开发质量的前提下，我希望你可以分派多个 SubAgent 进行并行开发提高开发速度，当然这一切要 Fable5 整体把控和检查。 我准备打造一个用于求职的的个人作品网站，方向为 AI 产品经理，你觉得我应该如何呈现？ 我做过的产品从最开始的 ChatBot、RAG+Workflow、Agent、Harness Agent，现在我还单独开发了一个个人版的 Harness Agent 用于介绍。 我已经简单设计了一个内容框架，但是至于风格、形式、内容、布局大致有要求和方向。 我现在需要你基于这个文档，全权授权你进行设计，我希望你创意无限，令人眼前一亮。 第一版快速设计，不纠结细节，我们时间有限。 我该如何规划如何呈现，是不是应该做的炫酷些，更具动效或者快速流转，来介绍我个人做了哪些事情？ 请你给我建议。 Help me！ 一些项目比如 Anna 做展示的同时我会上云，甚至让面试官上手体验。 但是其他过时的项目我觉得不用体验，用真实截图。 现在我没法把素材都给你，所以我希望你打个框架，风格、形式、内容、布局大致给个要求和方向，为什么是大致呢，因为我会让 Claude Design 去发挥和设计，所以你主需要规划内容就好，我希望也是叙事清晰，展现个人能力但也别吹得太过。 内容后边我会补充，现在主要是定样式架构，我需要你给我一交接文档，给 Claude Design 使用，快速决定。

2026-07-13：Hermes 取舍、Loop Engineering 与提示词优化

遗弃 Hermes 判断(代码=Forge) · Iris 合 main · Loop Engineering(自进化人格) · Create bug · 预设提示词优化(Sonnet)

  1. 其实我们迭代了这么久，最早关于 Hermes Agent 的设计是否可以遗弃？ 因为我发现好像并没有使用具体的代码，代码主要还是 Forge。 避免影响我的主要决策，你需要判断是否舍弃。

  2. 现在我需要你，把本地的桌面端更新到最新的 Iris 前端，然后验收合 Main，我先检查一下。

  3. 稍后我会给你一些新的想法，Loop Engineering 的相关内容，我们需要确定下后续的优化防线。 现在先 Review，在执行，确保内容正确，不要重复做已经完成的事情。 Create 中，还是只能选技能、Prompt 等这些任务，是强制性的，需要修改。 我刚执行了一个 Create 中的任务，执行到一半就断了，问题很大。 Anna 的 Home 页面中 Chat 和 Create 有很多预设的小任务，用来提升用户体验的，但是预设的 Prompt 写得非常差，因为是当时临时用作 demo 的，不适合生产级使用。 所以我需要你进行提示词优化，最好是用 Sonnet 去 GitHub 找对应的开源高 star 项目分享的相关提示词。 现在帮我优化这些子任务提示词。 Harness 是一种 Engineering，是我认为除了 LLM 之外，需要管控的内容，Anna 在设计时就预设了人格，我们也在产品的前端上有所体现，这是外放的体现，内在是通过 Harness Engineering 的能力实现 Agent 能力的持续化。 所以在 Harness 之后 Anthropic 还提出了 Loop Engineering，来提高模型的自主执行能力，实现长时间任务的持续执行。 我们接下来先解析，然后校正方向，面向未来开发，但现在更多也只是思考。 毕竟 Anna 现在的 Runtime 还是有 Bug，执行任务的时候会出现问题。 接下来请你先阅读下边的内容，确实阅读，连带着相关的内嵌有必要阅读的链接也读一下，然后看一下跟 Harness Engineering 相比，进化了哪些方向。 如果 Anna 想要进行自我进化，哦我们应该有哪些对应优化的点。 关于 Loop Engineering，在之前的基础上再优化一版方向，最终目的是进化出带有人格的自我优化路径。 https://code.claude.com/docs/en/agent-sdk/agent-loop#example-check-message-types-and-handle-results

https://claude.com/blog/getting-started-with-loops

https://code.claude.com/docs/en/agents

Harness Engineering for Self-Improvement

https://lilianweng.github.io/posts/2026-07-04-harness/

给出建议，不必奉承，不能先画靶再射箭。 诚实给出你的理解和见解，我不对你设限。

2026-07-14：组件化输出与流程图

output 增加组件展示 · 带代码的流程图输出

output 中增加组件展示，带代码的建议流程图支持输出

[内部临时图片链接已脱敏]

2026-07-15：Runtime 动效、答复排版与多轮线程

Runtime 动效(不要静态"瞬间")+L2 展开 · 答复排版(表格 Iris 化/emoji 全禁) · 问 Anna 多轮 bug · 多轮线程+记忆

先看一下最新的版本中我是怎么做的，看一下最新的 Iris 前端，版本别干错了。 我需要修改的是我希望在 Runtime 的运行过程中，是有动效的，现在的“瞬间”都是静态的感觉很死板，没有感受到 Anna 在跟我进行互动。 另外 L2 是否也可以展开呢？ 注意我是让交互感更强，让人感受到我是在等待 Anna 执行任务，她在干着，同时我也可以看到她做的对不对。 先规划方案，然后确定无误后，我提交给 Claude Design 进行设计。 使用 Opus 4.8 MAX 进行思考，我想动一下 Cowork 中，Anna 回答的样式，我发现回答似乎都是 Markdown 的原格式，表格内容都是带竖线，内容中还带 Emoji，并不符合 Iris 对 Anna 的设计要求，也不美观。 在问 Anna 的这一步也同样需要优化，一样，先规划方案，然后确定无误后，我提交给 Claude Design 进行设计。 另外，我还需要指出一个 Bug，在 Cowork 中，问 Anna 都是回答了当前看板最突出的问题，但是，我发现我再提问的话，还得问一遍之前的问题，而且第二个问题会消失。 这是实际 Bug，我还需要你查询一下，Cowork 是否运行了我们最新的 Longtime run 的架构和代码。 我有一些新的想法，你先看文档进行一版设计，注意严格按照 Iris 和 Anna 的人格设定，保持精致、端庄、简洁和克制的设计。 动用你的全部思考能力，确保设计达到要求。

  1. 多轮形态:问 Anna 变「对话线程 + 记住上文」

  2. 表格:答复里保留表格(做成 Iris 版式),这部分以内容为主，内容以什么形式呈现更好就用什么形式，后边我希望我们可以单独调整这部分的 Prompt；

  3. emoji:完全禁用，业务中还是严肃一些。

  4. 范围:「答复排版」一次统一到 Home/Reimbursement(荐,免得又三处不一致）现在就上，后边我们在做每一项的独立优化。 按照我给你的文件，执行设计工作，要求不变，最后给我一整套可交付的用于指导开发的文档，注意我可能也传了运行时动效和 L2，在原来基础上刷新，你可以大胆设计，我不对你做创意上的限制。 Claude Design 已经设计完成，请你根据内容进行 100%的视觉还原，注意 Fable5 进行规划、监督和检查，具体代码执行由 Opus 4.8 Max 的 Subagents 并行完成。

2026-07-16：答复优化、Memory 与 Crew 重规划

问 Anna 表格压缩 · Prompt 非前端 · Hiker/Finance 业务提示词 · Clear/历史/Memory · Crew 重规划(Asana)

我发现 Cowork 中的所有问 Anna 中格式，尤其是表格，被严重压缩了，阅读体验很差，另外，问 Anna 并不能支持向左侧展开，也就是我被限制在了右侧空间。 这些都需要改进，你思考一下如何优化。 这一轮修改我们不用 Claude Design 设计了，你直接修改。 不只是 Cowork，甚至 Chat 和 Create，涉及到数据分析、决策内容时，一些结论性的内容是否可以做一些强化，关键数据颜色上做一些区分。 现在我一眼看过去，没有重点。 所以输出内容中，是否可以带图表，比如柱状图或者饼图这些组件，来增强数据的呈现和趋势。 组件的配色参考 Iris，如果你认为需要 Claude Design 重新设计，告诉我。 不对，我误导了你，我们没有重点应该不是前端显示的问题，而是 Prompt 没有写对，所以才导致我们输出的内容有问题。 好了，现在我交给你一个拯救我的任务。 那就是针对 Hiker、Finance Kanban 所带有的业务属性，针对性的分别对他们写 Prompt。 我们最早设定 Cowork 每一部分都走 Forge Harness，但是也保留每一部分都有自己独立 Prompt 和 Skill 的能力。 所以，我现在需要你作为财务专家，结合这几款产品所连接的 MCP 中的数据，帮我丰富他们的提示词。 丰富提示词的目的是什么？ 是要让我们的输出结果更对味，更专业，更能切中用户提问想要的。 但是注意，你不能做 if else 式的问答对，这样扼杀了 Anna 的创造力，你要规划和引导 Anna 去做。 我需要 Fable5 来思考。 最后结合之前我们思考过得优化方案，再优化一次。 Fable5 规划指导，Opus 4.8 执行代码编辑。 Cowork 还有一些问题，我没有 Clear 当前对话的 button，我没看到在哪，我只能在当前对话中持续对话，我的上下文可能会很脏。 另外，我似乎没法查看每个问 Anna 的历史对话，且这些历史对话是否按照我们预设好的 Memory 系统，将最重要的经验和用户关注点列进当前系统的 Memory 里，比如 Hiker 的，要知道 Anna 是个可持续成长的系统，作为一个洞察人心的大小姐，Anna 的精干体现在了解用户需求和关注点上，并在不经意的时候提醒你别忘了。 我只是提了一些优化，我希望你能举一反三，在 Iris 和现在的架构上进一步优化。 你来决定，关于 Memory，看一下 harness-reference 里边有没有关于类似场景下的 Memory 处理方法，优先参考。 然后你自己优化。 Update Anna Destop APP into the lastest version, make sure when I open from my desktop, I can see the correct Anna we already optimized.

Before u begin ur optimization, I need U to review my decision, 因为这个 session 对话很长了，有一些关键信息可能会遗漏，我需要你来居中判断我的优化方向是否有误。 使用 Opus 导致了之前部分信息误判，现在我需要使用 Fable5 来修补错误。 (A) 先补 eval 验证已做的质量类改动是否真的更好。 B 我们单开一个分支来做。 C 的小坑我们需要完善，Clear 影响我们后边的测试过程。 现在我们要在 Anna 里重新规划一下 Crew 这个功能，因为业务方认为组织中的人员协同让他们特别关注。 现在我需要你全力帮我想清楚 Crew 的功能应该如何设计。 这是系统性设计，尤其是在结合了 Anna 的设计思想和理念之后。 我先说下我的想法和使用场景，请你作为一个 Google Product Manager 来规划功能和页面形式。 早期我们规划了 Associate 的旧设计，场景如下：“其实 Associate 我最开始的设计初衷是，解决项目制任务，我简单说个场景，你体会一下：我们现在要做一个新的产品设计（软件或者营销类物料）这会涉及到多方的协作。

  1. 任务拆解部分：我（现在是 Boss）设计了这个任务，我需要 Agent 帮我将任务拆解（我们会假设预制一些标准流程和最佳实践一些 SOP）和做 Workflow，给出任务路径和关键节点；

  2. 人员分配部分：这个时候 Agent 还需要结合我们团队里的人员的属性能力技能进行分配（有 PM、有前端有后端有 UIUE，有设计师，有外包供应商等等）；

  3. 任务分发部分：通过 IM 工具（websocket、Webhook 或者邮件）通知相关人员（人员可能反馈没有时间，或者需要协调，我们还需要做反向的调整和安排，要有反馈，但是 MVP 这个反馈可以是人为“我”Boss 进行调整）；

  4. 任务执行部分：可视化结构看大家做到什么程度了，由任务当前的进度和员工的反馈组成，任务触发下一个节点了，就能下推到下一个人（比如完成了 Product 的 PRD 推评审，审不通过返回改，改完推 UIUE 设计等等）；

  5. 内容优化：这本来就是对员工项目制工作的自动化拆解、分发、执行监督、反馈优化、进度可视的一个项目，未来部分员工会替换为 Agent，由 Anna 直接调用 Agent 进行任务接管。 不一定完全都是人类员工。 ”

  6. 除了一个 Graph/横向动态流程图和无限画布，我希望能在右侧支持员工跟 Anna 的互动，比如 Anna 让 SubAgent 做完了任务，要在这个聊天框中@那个员工，Anna 也会分配和审核任务，完成都需要@那个员工，这样更直观，进度也是公开的，也可以反馈到左侧画布的进度中。 我希望的可能并不需要房子这种形式，结合 Anna 的特性，更可能是动态的流程图或者更为贴切的符合实际需求的设计，重点可以参考一款产品 Asana（https://asana.com/）和 Asana Work Graph。 有几点重点设计，考虑到 Anna 的设计形式，我们的 Memory 是非常宝贵的资产，Hiker 会有自己的 Memory，Chat 和 Create 也会有独立的 Memory，我认为 Crew 中团队中除了个人有 Memory，团队会有共享 Memory，以确保这个项目的认知统一。 同时，Crew 还是我们的 Crew 账户的另一种沟通方式，这样 Anna 可以快速的将大家组织在一起。 这些都是我的想法，有很多 Idea，I need u to help me to find out the real feature, and help me to finish the PRD of Crew.

我还在纠结，但是因为右侧聊天框内容会反过来影响左侧的流程图，所以这个图可能会变，或者某个节点会长出新的分支或者很多小分支，因为涉及到人与人、人与 Agent 之间的写作。 所以我希望评估一下画布（Asana 怎么做的）的开发工作量，我们以效果为最终开发导向，有足够的理由我们在选择。 Crew 账户的设计有一点，我忘了说，在这个版本内，我希望是通过 Anna 的 Crew 账户来进行通知的，比如首页登录后右上角就会弹出 Crew 协作通知，然后引导进入 Crew 开展工作。 这样不用跳出到 IM 工具。 我要做到可信演示，我希望后期不只是产品研发和开发流程、简单的营销软文写作审核流程，我们 Cowork 中的一些流程，比如报销和其他的审批流也可以集成到 Crew 里来，这样叙事就连起来了。 Yes G1 Canvas is Ok，整个报销流程（not 报销审批流，我表述错误，报销审批其实是其中一部分）但是这个流程较为简单，我希望做一个真实的场景，比如 Anna 的某次功能迭代和设计流程（团队协作）。 频道长任务的拆解，我希望借鉴 Asana 的处理模式，要人机协同，第一性原理是提效、快速下推执行和检查、高效协同可视化进度，演示账号你来定。 剩下的内容你帮我决策。 下一步，请你思考给出用于 Claude Design 的 Handoff。 先阅读文件，我们参考 Asana 在 Anna 中新增了一个设计和内容，阅读文档并做设计，我不对你的设计做过多限制，但是一定符合第一性原理的同时，给用户美的享受，在视觉上动态化，灵动智慧，让用户有持续体验的愉悦，而不是接受任务被 push 的被动。 Grok release his Coding Agent named Grok Build, I want to check this code, and tell me what should we do now to optimize Anna to be a better Harness, espescially in Long time runing, Agent Loop, Memory/Global Memory, Tool Use, Evaulation and Sandbox.

现在主流程就是一条横向流程图，我们是否可以支持纵向+横向，因为部分任务可能并行，同时缩短视觉长度，另外这些框图，是否可以选择组件进行视觉优化，来强化更好的视觉观感。 其他部分你站在产品总监和 UEUI 专家角度，再进行优化，目前整体的观感克制大于美感，我需要更平衡的前端体验和效果。 我不对你做过多限制，只是为你提供建议。 现在是否可以进一步优化？ Can we design a backgroud for Crew Canvas? Making it looks better, the backgroud should fit the Canvas and dont have friction with others. Help me to optimize.

我觉得背景 Canvas 不太明显，感觉坐在车间地上干活的感觉，我希望是个精致的工作区。 我还想加入的一个设计是，比如我点击到某个节点，可能点击 Andy 或者实施这个组件，然后我希望应该是能展示目前的工作是什么，谁来执行，进度如何，一些明确的内容可以展示出来，避免整个项目运行过程中是个黑盒。 所以我希望你能继续帮我丰富这部分设计和功能，并设计相对应的内容/表单/组件/成果等等，我不对你设限，你随意发挥。 最后，因为现在主导航变成了 Home Cowork Crew，还需要考虑向左折叠的时候，icon 怎么变，画面怎么变。 再优化一版。 在融入 Anna 之前，我希望你去检索一下有没有业界专家或者大牛针对 Grok Build 做了分析和解读的，然后结合一下人家认为优秀的内容，与 Anna 现在的需求进行融合。 目前 Anna Harness 的优化已经演变为越来越专业越来越底层的内容，我需要你帮助我进行梳理/遴选/优化以及解释，用你的知识来引领 Anna 的进化。 Fable5 Judge and Check All Optimization Anna Need Again, if all things right then combain the findings before, arrange develop plan. Then do it.

我已经交付 Claude Design 设计，并由设计师提出了一些修改建议，请你分析文档然后开始进行视觉级复刻与开发。 依旧是 Fable5 统领全局规划和把关，由 Opus 4.8 MAX 进行代码执行。

2026-07-20：Crew 搭建与实测优化

Crew 搭建实测 · Kanban 卡贴化 · 作品站 · 4 优化点 · Enter 发送 · v0/v1/v2

近期开发任务：

  1. 完成 Crew 的搭建和测试；

  2. Kanban 卡贴化，参考 Kimi Code 的看板页面；

  3. 参考 SuperHuman 的主页面，打造个人作品页。 Crew 测试：

  4. 无法查看产物，比如 PRD，我应该能看到实物内容，我确认无误后才进行评审；

  5. 操作逻辑简化；

  6. 未接 Anna 底层 Harness，Anna Agent 在被@后，没有任何反映；

  7. 有些任务可能不是单线程（瀑式单线程），可能是多线程的，需要丰富功能；

  8. 有些 Project 中间有线连接，有的没有。 整个 Crew 还需要你自己运行和检测，而且要以视觉形式进行检查。 先进行修改，有问题不明白的先问我。 先回顾一下 Context 以及 我们之前规划和设计的重点和巧思。 然后我整体看了一遍，现在有些新的想法，需要你帮我诊断然后看一下问题出在哪里。 优化点 1：现在查看产物是在对话框里，有点太小了，比如 PRD 文档，我希望支持在左侧 Canvas 地区支持放大预览，或者下载到本地预览。 优化点 2：点击 Agent 执行任务出现{"detail":"Cannot start task 'task_4_design': status is 'submitted', expected 'assigned'"}

不仅如此，点完之后我们的连线消失了，不知道为什么。 优化点 3：Agent 开始执行任务后，我发现没有那种动效的圈或者其他 runtime 表示该任务正在执行，同时 Anna 的思考 Runtime 有个问题，就是里边都是 Markdown 格式，呈现出来的可阅读性较差。 执行 Trace 打开后没法点击“瞬间”关闭，然后整个输出物阅读性差，我没法看到产物具体是什么。 是不是可以在对话框中增加一个附件是产物的功能，直接让大家在对话框中就能看到产物的文档、链接等等。 优化点 4：我直接在对话框中 Shift+2 出现@，结果没有拉起@成员。 同时我为 Andy 分配了一个新任务比如“New mission, you need test all features”并没有反映到 Canvas 的图里，或者有进一步双方确认的动作和交互，也就是说 Anna 没有在这个过程中监控整个对话框，她没能起到动态管理和监察、动态分派任务的职能。 整体帮我提升一下高可用度，另外，我现在还是觉得 Canvas 的区域，包括整个流程的组件有些平淡，现在整个区域看过去不够突出，我们可能会更明显的配色和设计方式来呈现。 还有一个全局性的修改，我习惯输入完成后，按 Enter 直接发送信息，目前 Anna 所有的对话中都是 Enter 换行，所以我需要你修改一下，Shift+Enter 为换行，Enter 为发送信息。 现在请先帮我诊断问题，然后我准备让 Claude Design 重新设计一下。 所以你需要给我一个新的交付设计的设计需求说明，然后我们去结合之前提到的优化点，重新设计一下对应的内容。 之后在进行开发。 我们基于之前的版本，在实际测试后给出了优化设计，但是我现在需要你先设计好修复好前端，然后再继续执行代码级的修复任务，你先按照我给你的内容，先行设计优化。 有需要我确认的，给我推荐项让我决策。 v0 版做原型、v1 版市场验证、v2 版重新设计。

2026-07-21：Crew 评审、产物与 Canvas 可用性

Crew 测试优化，设计一个轻量任务，Boss+Agent+Andy 账号的，等待周限重置；Crew 完成后进入 Harness 底层的 Runtime 修复，同时 Grill myself 核心竞争力是什么

个人信息汇总+页面同步。 RAG+Agent+GEO+Lingee Harness/ Anna

PRD 的评审页面的提交，我不知道要提交什么，然后验收标准里的内容

“验收标准评审按此打勾

目标、范围、验收标准三者清晰

关键路径无遗漏

登录页三态(空态/校验中/错误)口径已定义。 ” 无法打钩，不能评审，卡住。 点击提交后，出现一个输入框，但是输入内容后提示：Task 'task_15_prd_review' is a gate task; use review_task() instead of submit_task()

我觉得基础功能开发的很足，视觉上也可以了。 但是，对于一个刚上手这个系统的人，我觉得功能性还是太复杂了，给我的感觉是，任务很清晰，但是我不知道怎么操作这个 Canvas，要确认的内容有点多，你能不能从用户使用角度，去做一个优化，不用顾虑原本的设计，遵循第一性原则，高可用的清晰使用路线。 我又检查了一遍，还是有一些问题。 现在产物的提交有点问题，以“**登录页重设计:空态/校验中/错误三态”中的“执行九屏全功能回归走查，输出问题清单”为例，第一步 ①产物，我在哪提交，我为什么不能上传文档，下游能不能读取文档？ 为什么我点了提交后出现了一个输入框，这个输入框是干什么的？ ②验收标准是基于什么标准制定的，我依靠什么依据进行点选。 ③这个执行过程是干什么用的？ 现件留位是什么？ **

PRD 起草，为什么我没法在图里 Canvas 中定位到聊天框里的文档，我不知道那个是哪个文档，没法对齐和定位。 聊天框下方为什么要出现“Enter 发送...”然后导致 at 成员 at 任务都换行了。 打开抽屉和全幅阅读的差异是什么，这两个功能都出现在这的目的是什么？ 思考清楚之后再动手，尤其是这个 Crew 很多都是全局逻辑，你需要仔细想清楚前因后果以及关联性后在执行修改任务。 Fable5 思考，Opus 执行。

2026-07-22：Anna 品牌人格与视觉收敛

人格

  • Anna 是人机同 Crew 中的 AI 团队成员，具备大小姐式的端庄、教养、聪明与原则感。
  • 她尊重用户、乐于帮助人，也保留自己的判断，不以迎合换取认可。
  • 她快乐时热烈，安静时像鸢尾花，兼具成熟、灵动与鲜活。
  • 初版年龄设定约为 16 岁，视觉评审后上调至 22 岁，以增强成熟感和团队可信度。
  • 核心表达为：饱含善意，探索世界，做一个卖铲子的人。

视觉

  • 欧亚混血特征、黑色长发、清晰而克制的神态，人物形象与鸢尾花元素共同构成识别锚点。
  • 主视觉沿用鸢尾紫、薰衣草紫、金色、暖瓷白与墨色，金线只用于滚边、纽扣和局部细节。
  • 服装以现代立领、长裙或团队管家式制服为主，可保留一套女仆装作为非主要造型。
  • 画风服务于人物气质和产品落位，瓷与光可以保留，也可以在更适合 Anna 的方向下调整。
  • 人物保持成熟、周正和友善，避免过度幼态、性感化、赛博义体化或夸张萌系表达。

资产

  1. 一套通用 Logo 或头像，用于应用图标、成员头像、菜单栏和 GitHub 展示。
  2. 一张关键人物形象插画，用于登录页、关于页和品牌展示。
  3. 必要时补充呈上、等待、失败等少量状态插画，按真实页面需求逐步增加。
  4. 功能图标继续使用产品内的矢量图标体系，避免制作缺少落位的大量插画。
  5. 浅色与深色版本保持同一人物识别和色彩语义。

2026-07-23：从 Pi Agent 学习 Harness 与 Agent Loop

回归 Anna 最核心最重要的主题，Harness 和 Agent Loop，因为我在学习的过程中，是逐步探索的，没有一个具体的框架，在开发中又是由 Andy 和 Fable5 引导开发，导致我很多内容不清晰，并不能有效的进行沟通。 现在我想研究一个最简单的 Agent，Pi Agent，我们通过分析它的源码（https://github.com/earendil-works/pi/tree/main），来和 Anna 对齐。 为此，我需要你 1. 先在别的文件夹拉取 Pi Agent 的源码到本地；

  1. 我会给你一个我在 Online 获得的一个讲解文档，我是通过阅读它来了解 Pi Agent，所以拆解和理解代码（https://dg-ai-notes.pages.dev/）你看要用什么方式呈现；

  2. 对照 Pi Agent 的源码我们分析 Anna 现在的代码。 注意 Pi Agent 架构简单，但更适合我学习，我们最终的目的是对比 Anna。 这样放弃开发转向学习的过程，是为了更好的分析和解释问题，我要彻底弄明白 runtime 的运行原理，这样我才能指出问题在哪，如何才能进行优化，这也是我去 LA 的 Flight 上想明白的。 所以接下来我们将不会开始开发，而是进入一段深入学习时间。 既然是学习，就不要用比喻和类比的方式尝试让我模糊理解内容，而是基于专业名词让我理解正确的说法和代码，现在请你开始任务，开始再一次教导我。 我拒绝这种我看讲义的方式，你需要给我讲解内容，你现在是老师，我是一个不怎么懂代码的产品经理，你需要给我讲清楚。

  3. No，模型不会保存，而是通过重读来实现上文的读取；

  4. 不，是模型调用了 Tool 进行执行；

  5. While 没有 Tool 使用了，就会停止。 Btw，这种方式我很喜欢，我现在希望你按照这种方式直接把剩下的授课整理好，内容可以丰富，但要真实，因为我会看 Pi 也开发了 Anna，我会联想和参考。 我希望你能把剩下的内容整理为一组 HTML，这样我们可以跳出当前对话框，我阅读和学习后，带着问题回来找你。 请你把我当成有开发经验但因为 Vibe Coding 不求甚解的产品经理，我需要了解 Anna 是怎么运行起来的，如何能变得更好（具体指出，精准命中）。 接下来我期待你的 HTML，甚至你可以加一些简单的动画，美观不是核心，知识是核心，读懂学会是核心。 第一章我学完了，我来确认一下我的想法，请你判断是否正确。 模型并没有调用工具，模型只是生成了一张工具调用清单，是否正确，那这个 tool calls 清单是模型依据什么生成的呢？ 模型自己读取了上下文？ 比如在一个通用场景下，他可能不清楚我提供的是哪个系统的内容，当然我可能会给他一些具体的 Prompt（毕竟 Prompt 越清晰，执行任务更清晰），特定场景下我肯定预设了一些内容。 但是这个整个体系是怎么实现的。 我这些是业务侧的一些思考哈。 好的老师，因为我是个 笨蛋产品经理，不太懂代码，但是我能看懂个大概。 那么我先说下我进一步的理解哈，如果说我们在做一个 Finance Agent，通过 MCP 连接系统的，其实如果我们想提升他的准确率 或者其他指标，我们最应该做的应该是维护和优化各类 Tool，以及 Tool 的 Description，或者说更粗的 Skill，来约束 Tool 的调用。 我尝试回答问题：

  6. 转述后输入不同，模型行为会改变，因为输出的 tool calls 不一样，后边的 turns 会变；

  7. 模型应该会根据工具返回的空内容回答“没有连接 ERP，所以没有数据等等”

至于我们的提问和思辨过程，你先单独存着，我们全都学完了整理合并到 HTML 中，现在我们先关注问答和我的想法

等等，我们先讨论和确定一个规则，这是 fork 一个 Session 专门用来问答的。 首先，我希望学到通用知识，绝对不是依照 Anna 的逻辑来判断我说的对不对，为什么这样？ 因为我们要通过 Pi Agent 来优化 Anna 啊，所以我们知识和判断的来源一定是官方信息或者你自己存储的正确的通用知识、Pi Agent 的做法。 所以接下来请在这个 Session 记住这个规则，我们来学“已发布的课本知识”“行业共识”。 这个规则你是否同意，你是老师，不要迎合我，你得判断怎么教学。 如果同意，给出对应上一段对话的解释与回复，如果不同意就维持原装。

  1. 最可能输出幻觉，因为 fall back，这也是危害最大的，因为编造了数据。 第二种可能是历史数据，参考内容进行推理的；第三种是反馈没有工具，进程停止。

  2. 我会在 Tool Call 之前加一段检索校验的代码，确保有这些工具，没有全部复核就返回错误内容。 或者是正常进行，但如实反馈，在下一轮对话中让用户检查错误信息。 以后的问题都先给我标准的答案，让我建立正确认知后在分析，先帮我把第一张的内容总结一下，然后我去学第二章。

原则与规则

【耐久原则 · 可靠性工程】响亮失效(loud failure)vs 静默失效(silent failure)。 失效的危害程度,不取决于它多严重,而取决于它是否与成功难以区分。 会报错的失效是便宜的;伪装成正常输出的失效是昂贵的。 提示只能激发,不能创造能力。 Tool 和 Functions 一般建议少于 20 个。 Frozen Snapshot>在会话开始或 Prompt 重建时，把当时的 Memory、User Profile 等上下文读取出来，组装成一份固定的 System Prompt；在该会话后续调用中反复使用，不随底层文件实时变化。 当用户发送一条消息，在 Context 的组装：Context=

一次请求=system prompt+Messages+Tools 组成。 静默失效的危害大于响亮失效

context = 本次请求实际发送的消息列表 ·

role(system/user/assistant/tool)·

tool call = 模型生成的申请单 ·

observation = 工具结果包装成的消息 ·

turn = 一次响应 + 其工具执行 ·

agent loop · harness · tool contract = name+description+schema ·

groundedness = 可溯源性 ·

fail-closed = 默认拒绝 ·

preflight = 调用前的前置校验

Agent Loop：一次说不清可以多来几轮

Agent Loop 不是"一次做对",而是在不更换模型的前提下,通过多轮交替的推理与行动,把外部信息持续富集进上下文,从而完成单次调用做不到的任务(ReAct / test-time compute)。 它扩展能力、顺带提供错误自纠,但无法修正一个错误的目标。 【官方/学术】你刚才重新发明的东西,学术界有正式名字:ReAct(Reason + Act,Yao et al., 2022)。 核心主张:把"推理"和"行动"交错进行 —— 每一次行动产生的观察,成为下一次推理的输入。 之所以有效,是因为它让模型能够基于它原本不掌握的信息做决策,而不是一次性从参数化知识里硬猜。 【学术/行业共识】这有个当下很热的名字:test-time compute(推理期算力)/ inference-time scaling。 核心结论:在不换模型的前提下,通过让模型在推理阶段多做几步(多轮、多次尝试、自我检查),可以显著提升结果质量。 追问是最贵的选项,因为它打断用户、消耗人的注意力。 它应该排在最后,不是第二。 而 UI 状态是确定性信息 —— 用户已经用鼠标告诉你了,让模型去猜或去问,是设计缺陷。 这里有个反直觉但很硬的事实:在信息不足的情况下,更强的模型不会变好,只会更自信地编。 每增加一个机制,必须同时问:它触发时、失败时、被跳过时,事件流里看得见吗?

看不见的机制等于不存在 —— 无法审计、无法调试、无法向任何人证明它工作过。

Compact 由单独模型执行一次压缩任务，保留：

1.请求与意图 2.关键技术概念 3.文件与代码(全路径+完整片段) 4.错误与修复(根因+修法) 5.问题解决 6.全部用户消息(逐条按序) 7.待办 8.当前工作(精确到可中途接手) 9.下一步(带原文引用防漂移)

一个新的想法和问题，就是上文提到的装配，装配是什么，是 Orchestrator 编排么？ 如果装配发生在调用模型之前，那谁负责的装配指令呢？ 也就是从用户输入的 Prompt 到执行明确的装配，这个过程是 input 到模型里，模型理解了 query 然后进行指令装配？ 还是 Harness 执行的装配，但 prompt 扩写为 Query 经过了一次 LLM？ 我现在问题很多，我正在逐渐摸清路线，加油老师！

对话与 Agent Loop 流程

用户输入(一句话)

↓

① 入口层 接住请求,确定 who / where:谁、哪个工作区、哪个会话

↓

② 编排层 决定 what:这次请求属于哪个场景/能力

├─ 选定场景配置:人设、用哪份技能文档、这个场景允许哪些工具

├─ 前置校验:依赖的后端可用吗?权限够吗?(第 1 章原则 4 的①②层)

└─ 建立本次运行的记录(用于审计、恢复、观测)

↓

③ 【装配】 纯代码、确定性、可单元测试:

├─ system = 人设 + 技能正文 + 输出纪律 + 运行期上下文(如可用文件清单)

├─ messages = 历史消息 + 本次用户输入(通常套一层模板)

└─ tools = 工具注册表 ∩ 场景允许集 − 场景禁止集

↓

④ 循环层 把这个请求交给模型 → 拿回响应 → 执行工具 → 再装配下一轮 → …

除了回答之外，我还有个想法，就是我现在还是没清楚从用户输入一句话到有明确的编排指令的这个过程，是怎么发生的，模型参与了多少，Harness 参与了多少。 正常来说，用户输入的 Prompt 因为不够详细，可能导致信息不全，如何去确保按照用户的期望去找 who、where、what，或者说是谁理解这个过程去拉起这个任务？ 我可能还没表达清楚，所以我可能需要你按照之前的流程，详细的帮我解释一遍整体，哪些模型参与的，哪些 Harness 参与的，我这个整个链路随着细节内容的推进，容易不通畅。 需要建立正确的框架再去深究。 回答问题：

  1. 我要查询输入编排层的内容是什么，看看调了哪些工具，是否拉起了对应的内容，然后再看返回的结果是什么做符合判断。

  2. 我不同意，财务看板应该约束在财务领域，避免注意力偏移；

  3. 按需加载，Skill 天然有渐进式披露的能力，我只需要读取 yaml 头就知道这个 Skill 需不需要用，所以我可以按照这个规则进行按需加载。 我先说明我的认知，我错误理解 Agent Loop 是一次把任务做正确，实际上这是个鲁棒性项目，是通过多轮 Loop 实现信息的不断富集，更高参数和能力的模型+线索们，获取正确的结果。 回答：

  4. 歧义我认为要分有无上下文，有上下文，可以从上下文对话历史中推断，没有就立刻向用户追问；

  5. 确定性区域和概率性区域都有，用户输入带有歧义，导致按照错误任务进行循环，越来越挫；

  6. 没必要，其实这一步会是 Agent Loop 的一部分，但是也分情况，如果没有 Harness 的单向工作流，那是需要补全 Query 的，比如 RAG。 我几乎忘记了，我们还有 Grok Build 这个开源项目可以作参考的，我们之前研究过，相较于 Pi Agent，Grok Build 拥有更加复杂的 Runtime，整个产品商业化程度更高，所以我们也同样可以用作参考，你先看下 Grok Build，是否有必要更新进我们的授课 HTML 里，可能 Pi Agent 最简单，也最好懂。 不了，先保持现状，我们还是先学 Pi Agent，后续必然用通过 Grok Build 来进行功能强化的。 回归课程本身，第二章的课程我没看懂，我不知道第二章要传递的是什么，可能是为了让我读懂代码？ 那我现在有一些关于循环过程的想法。 其实我很早就想改变 Anna 的底层设计，可一直没有实现，现在 Anna 的通用能力太弱，我本质是想一整套强力 Harness+特定领域 Tool 的方式来驱动 Anna，但是 Andy 为了尽快实现功能，换成了分领域的，这导致 Anna 的底层 Harness 能力被拆分太碎。 我们用 Anna 进行 Chat 和 Create 时，效果就很差。 所以我们后续会按照 Pi 的方式进行，Anna 会变成超强力通用 Agent+单独领域强力 Tool 的方式进行，我们还需要跟 Grok Build 看一下。 现在回归主题，第二章的核心是什么？ 另外 Andy 分享了一张 Pi Agent 的 Trace 和 Turn 的图片，你看一下，是否有价值有意义？ 可能也是我之前方向没跟你说好，这又何尝不是第一章内容的实操呢，你这种顶级 LLM+最强 Harness 都会出错。 所以现在修正口径和路线，重新帮我梳理一下 HTML 中的课程，我们也有新内容和新想法，重新帮我跑一个 HTML 出来吧，如果你觉得 Context 太多，你可以自行决定是否 Compact。 我觉得这一版，不像教科书了，像是定制化的解释，不好，形式上甚至不如前一版。 你现在有点谄媚在做取悦我的事情，你是老师，教案你自己定。 我是学生，我提出要求，你应该是思考怎么教的更好，不是按我的要求改教材。 我看了新的第三章，这是问答。

  7. 为何携带申请单的 assistant 消息必须保留在历史中?若仅保留工具结果会发生什么?

  8. 设置回合预算与不设置回合预算,各自的典型失效场景是什么?该取舍与运行是否有人值守有何关系?

  9. 某工具返回 {"error": "该客户不存在"}。 依 3.4 的判据,应交回模型还是终止?

  10. "通过更强的模型加线索来获得正确结果"——这一表述错在何处?

  11. 模型本身没有记忆，通过上下文带的信息和历史内容来判断执行结果和工具调用情况，如果只保留工具结果，这一题我不是很理解；

  12. 回合预算这一块我也不是很理解，什么是回合预算；

  13. 交回模型，让模型继续判断和调用工具解决问题；

  14. 运行过程中模型本身并不会做改变，换了模型也是重新开始。 这句话我认为原本上是没问题的，更好的 LLM 和模型意味着更强的推理能力和 Agent Loop，考虑的更清楚，结果会变好。 我需要你来审校一下新版本的教材内容，如有问题，直接你进行修改。 首先第四章模型接入层和第五章工具系统我都不太理解，脱离了代码和演示，我这个产品经理根本不知道是哪块的什么内容在说什么，第六章我看懂了一些，渐进式披露这一块我需要跟你确认一下，比如，我想在页面上呈现一个任务完成模型所需的四步，比如先干什么在干什么后干什么，这其实可以通过一个模型返回的 L1 Turn 层事件名称来呈现。 至于 L3，已经是具体的代码内容了，或者产物的内容。 那我的产物是怎么被看见的，比如我生成了一个 word 文档，肯定是代码形式（oh 对，整个 word 里边的内容是 LLM 基于 tool 来写的，内容来源于返回给 LLM 的 message，然后 tool 调用比如 py word 去输出这个 word 形式的文档），他又是怎么转化成产物（word.doc）的，时又调用了一个输出 tool，执行了整个任务么（这一系列的任务规划是 LLM+harness 的结果）

并行修改吧，你安排 SubAgent 去修改其他章节内容，然后你来回答接下来的问题。 我有几个问题：

  1. 什么是 Schema，为什么到处都有这个定义；

  2. 我理解为什么界面上不能呈现由生成的状态栏，因为模型可能欺骗，代码是输出结果，这个是真实的，那么假如我要做一个优化，比如我执行了某项任务，我作为用户输入了一段 Prompt，有着明确的要求和产物需求，是否能有一个界面告知用户：Anna 第一步会做什么、第二部会做什么、第三部会做什么，这样是不是 LLM 分析了任务后，给出了一个 plan，我们规划后在进行执行。 这几步当然不是一个 turn，可能是很多个 loop 完成的。 那如果我要获取这个 plan，是不是直接让代码输出 LLM 的 plan 结果就可以，这是不是一种前置驱动，Spec Coding。

  3. 我现在很疑惑，模型到底能不能思考这么快，触发这么多任务，所以 API 每次输出给 LLM，怎么能保证又快又好的全部完成，怎么协作，我知道可以做到，这个就是编排么？ 我问一下天气，和让他出一份分析报告，其实在某种程度上可能复杂度一致，但是问天气和开发一个组件的复杂度肯定又不一样。 回到这张图上，你觉得这张图代表了什么，在昨天系统学习完所有章节后，我现在对 Harness 及 Agent Loop 有了一个认知，现在要进行验证和拓展阶段，所以你需要结合 Pi 和 Grok Build 的内容来验证我的猜想，决不能迎合我，对的就对，错的纠错，引导我。 先尝试回答问题，首先我对事件这个含义还是不清楚，他的官方英文是 Event？ 具体含义是什么呢？ 跟 Observation 有什么区别。 如果只是从架构上描述这个 Event，那我们是没法得到具体的返回内容的，也就是你能看到在跑，但是无法知道具体再跑什么，因为都是代码在执行，你没有 summary 的过程，如果换成 Grok Build 这种方式的话，说明团队已经约束好了具体的 Event，只要触发，我们就能知道了。 至于说具体有哪几种 Event，我不清楚。 那么问题来了，Grok Build 这种模式是不是 Pi Agent 的延伸，或者说是两种阶段？ 两个模式？ 我现在想不太清楚，我需要解答。 我先回答：能查出走了哪些 Event，但是查不出除了这些 Event 之外的具体原因；至少需要触发、调试、结果、被跳过、结束等。 我觉得我们的对话出现了问题，一是越来越抽象，背离了学习和教学的本意。 所以我选择 Compact，然后再起新成，我现在需要你做什么呢？ 只有一件事，我不了解如何才能系统性的搭建一个 Harness Agent，作为产品经理我需要了解哪些内容？ 那么 Pi 和 Grok Build 只是为了规避幻觉让我们有个参考锚点，Pi 足够简单，Grok Build 商业化验证过足够可靠和完善。 那我应该学到什么程度，才能更好的沟通和交流，才能更好地去优化 Anna？ 我需要掌握哪些知识》

继续，完成这份内容，我希望他基于行业公开内容（Anthropic and OpenAI Blog and Dev Docs）需要参考、示例、甚至动画，我希望我作为 PM 与之相配。 不是？ 我不说了知识要从行业共识和 A/O 两家的官方文档或者 Pi Grok 的内容中看么，怎么有些内容还是直接拿了 Anna 的代码做演示，Anna 是我们要优化的产品啊，你先射箭后画靶我怎么看出优劣？ 我需要的是正确的通用知识，如果特定内容需要用到 Anna 代码做演示的时候也可以。 先理解我意思，然后看一下是不是有这样的问题。

Anna 待优化内容

  1. 我在阅读 Harness Agent 建造清单之后发现了一个问题，就是 Anna 在 Assembly 环节的设计可能要按照 Grok Build 去设计，我们不能每增加一套功能 tab 就刷新一遍 Anna 的 Tool 白名单，随着后续功能增加，这个 Tool 名单可能会爆炸式增加，而整个 Anna 的 Cowork 部分的 Tool 和 System Prompt 是由该板块的 PM 独立负责的，他们会单独写这个部分的内容，所以 Anna 在 Assembly 的时候应该是阅读当前的页面、场景、权限管控、Tool，这个逻辑，如果我们单独维护这个白名单，我感觉有点死板，并不能表现 Anna 能够持续进化的能力。 Anna 也是应该能够按需加载的。

  2. 关于 Compact 我有很多想法，首先，我想知道这个 Compact 是怎么实现的，是调用了某个 Tool？ 然后 Compact 之后的 Context 是什么样子的，去掉了哪些内容，保留了哪些内容。 另外，窗口上限跟 Context 的关系是啥，跟 LLM 的关系是什么，Compact 的时候跟 LLM 的 KV Cache 有什么关系？ 如果缓存命中率高，有什么效果？ 对于 Anna 这种企业级的，Compact 又需要明确注意什么和保留什么内容？ 同时 Just-in-time 看起来有种图论的味道，也是按需加载的感觉？ 机构化叙事是如何跨多次压缩场任务的？ 以及 SubAgent 这个我常用，这三种方式的成本和质量又如何判断呢？

2026-08-05：暂停 Crew，回到 Harness 与 Agent Loop

Check Anna Process，我现在暂时放弃 Crew 的设计和开发，先帮我合并到 main，然后我要开始修复 Harness Runtime 了

这似乎是一个用 Pi Agent 作为底层框架开发的 Harness Agent，我比较中意，我更中意他在 Pi Agent 基础上所搭建的这些内容，请先帮我研究一下这个项目，然后看一下这个项目是如何使用 Pi 的，如何搭建的，这个人的思路是怎样的。 以及 Anna 开发到了现在，Agent Loop 部分是否应该换成 Pi Agent，然后去开发不同的 Tool 和 Plugin 来实现业务。 Buzz，我在 GitHub 上看到了这个 Agent 对话工具，这不就是我们 Crew 想实现的效果的一部分，但是可能他还没开始画图（DAG），我们是用图来驱动的。 所以研究一下这个项目。 看一下我们是否可以用 Buzz 的思想，来优化一下 Crew 的效果。 我希望的是人→Agent 可以跑通，Agent→人一样可以，后续我们可以替换 Crew 里 Anna 的主角色。 Fable 5 你觉得呢，你现在是从算法角度看一下，我们之前的架构其实比较旧，但并不是说它不好，因为是多个迭代版本修修补补起来的。 但是现在确实有些不满意，还有 Bug，你现在需要审查一下现在 Anna 的 Agent Harness，好用么？ 长时任务能跑下来么？ 如果去跑评测集能成功么（不用真的跑，我们建设完了再跑）？ 我认为 Pi 是可以作为我们的 SubAgent 去跑任务的，但是现在，我需要一个顶层设计，需要你 Fable 5 来帮我判断，怎么优化，是继续打补丁好一些，还是重新规划好一些？ 你要客观判断，冷静克制。 我继续补充一个信息，确保规避早期设计的误导，早期我们把 Anna 设计成了一个服务于 ERP 或者外部系统的这样的 Workflow 工具，核心错误设置为了 ERP。 那么 Anna 本身就应该是 Agent，我们重点通过约束 Agent Harness 和 Agent Runtime 实现 Anna 的智能化，为未来的 AGI 探索方向。 那么在类似 Crew、Work 这种场景下，Anna 会规划和派遣 Agent Instance 或者自己就是，来完成“问 Anna”“crew 中的任务"，所以如何进行优化，让 Anna 通有更高智能，我认为是先从学会 Agent Loop，管控好自己的 Runtime 开始的。 那么我们现在对于 Harness Engineering 有了一定了解，我们需要梳理 Anna 的运行逻辑，从工程上先让 Anna have 更好的运行框架。 所以，在我这个补充的信息上，我们继续思考一轮，不要受之前项目中原始设计文档的束缚，我们想更多一些。 然后我们在看看方向。 首先这个描述，太抽象了，我不理解，我们在解决工程问题，不是哲学问题，参考一下 Cloudflare 新的 Trace Agent，看下人家的方法论和定义，用专业的词汇来对齐，然后我们再来规划一下 Anna。 另外，整个 Trace 我们是否可以用到 Anna 里，我看 Waku 也有个 Harness Trace 的页面，我可以看到 Anna 是怎么工作的么？ 我们是不是能融合一下？

  1. 核心任务，规范术语描述；

  2. 分支任务，看下 Trace 是否可以图形化展示在 Anna 中。 思考一下，如果是在真的项目写作中，我如何通过 Buzz 这种对话模式+Agent 协作的方式，配合这种 DAG 图来实现智能的规划？ 我们的业务如何设计，交互逻辑应该是怎样的？ 时序是怎样的，我们之前没有想清楚，现在是不是可以从实际效果出发，参考 Buzz 实现整个 Crew 的进化和迭代？ 这一轮以 Cloudflare Agent Development Lifecycle、Workers Traces、Waku Agent、Pi Agent 和 Buzz 为参考，先统一专业术语与方法，再回到 Anna 做架构判断。

  3. 核心任务：规范 Harness、Runtime、Run、Event、Trace、Tool、Memory 与 Eval 等术语。

  4. 分支任务：判断 Trace 能否在 Anna 中形成可阅读、可下钻的图形化展示。

先做规划，详细的 SPEC 计划，因为我们之前花了很多时间来设计 Anna 的前端，这一次又要有新的设计，但我们依然以 Runtime 的实际效果为核心，所以，考虑好了在动手，为了 Anna 更加智能的完成任务。 稍等，我需要确认一下，在新的 Anna 中，从用户输入任务点击提交后，不同模块的 Harness Runtime 怎么规划的，整个 Trace 过程是如何实现的，Trace 涉及到的部分分别是哪些，现在的完整度有多少，我理解的是，后期我们会在 Tool 和 Memory 上投入大量精力，Skill 的制作也会适配我们的场景。 但现在我们要处理底层的 Harness + Agent Loop，现在，请你解释清楚后，在执行开发，我们确认没问题了，再进行下一步。 然后现在你可以找一个小帮手：github 上的 https://github.com/mattpocock/skills/tree/main/skills/engineering/grill-with-docs，用这个技能来帮助我们理清思路。 我需要系统理解 Harness Engineering，并明确一名企业级 Harness 产品经理需要掌握的知识、职责与能力边界。 Harness Agent 在从 0-1 搭建过程中会有哪些常见问题，结合企业（ERP 场景）的实际业务场景，一个产品可能会面临哪些工作、决策、badcase、解决方案。 Harness Agent 会出现什么问题。 如果我在一个面试的过程中，我需要知道哪些信息，才能经受住面试官的拷问。 以 OpenCode 为例，我们需要搭建一个真实的这样的一个项目。 不用管我现在 workspace 里有什么，我们要的是一次产品经理视角的全新探索。 内容详细尽可能丰富，但一定要真实、有理有据，最终 HTML 呈现。 没问题，但我需要你对抗性 grill 一下，看看是不是遵循了之前我们完善后的设计。 注意，我最后确认一下，是否满足了“我继续补充一个信息，确保规避早期设计的误导，早期我们把 Anna 设计成了一个服务于 ERP 或者外部系统的这样的 Workflow 工具，核心错误设置为了 ERP。 那么 Anna 本身就应该是 Agent，我们重点通过约束 Agent Harness 和 Agent Runtime 实现 Anna 的智能化，为未来的 AGI 探索方向。 那么在类似 Crew、Work 这种场景下，Anna 会规划和派遣 Agent Instance 或者自己就是，来完成“问 Anna”“crew 中的任务"，所以如何进行优化，让 Anna 通有更高智能，我认为是先从学会 Agent Loop，管控好自己的 Runtime 开始的。 那么我们现在对于 Harness Engineering 有了一定了解，我们需要梳理 Anna 的运行逻辑，从工程上先让 Anna have 更好的运行框架。 所以，在我这个补充的信息上，我们继续思考一轮，不要受之前项目中原始设计文档的束缚，我们想更多一些。 然后我们在看看方向。 ”

没问题，你的判断没错。

2026-08-06：Better Harness 诊断与底层重构裁定

  1. https://github.com/QoderAI/better-harness 这是一个 Harness 测评和优化框架，我希望你先用这个框架测试和评估现在的 Anna，差异在哪里。 以这个测评框架作为唯一判断，你不能没有实操基于代码进行判断。 然后在得出诊断结果之后，重写我们的 SPEC 文档和 PRD 文档，删除旧世界的内容。 我们要收敛检查范围，先保证核心的 Trace 能够跑长程开发任务。 关于 Anna 当前的优化需求：

  2. 对照 Pi Agent（最基础 Agent Loop、轻量 Harness）、Grok Build（商业化 Harness）来看，在我们的需求下，现在 Anna 还缺少什么；

  3. Anna 有没有 Memory 系统，比如类似 Codex 的 Agent.md / Claude Code 的 Claude.md，Anna 有没有这样的 init 文档来记录 Memory；

  4. 在 Cloudflare 的 Trace Agent 要求的模块是不是齐全；

  5. 现在这个 Better Harness 的分数怎么提（我们不是为了分数针对性优化，而是通过优化 Harness 来自然获得分数增长），实操和实际运行是唯一验证，完成所有优化后，确认 OK 再跑 Better Harness 评分。 我们避免点状的针对性优化，现在整个架构系统性的腐烂和崩塌。 所以存在重新开发底层的可能，我要求大胆修正，甚至推倒重建以获得更好的性能。 我们同样跑了一轮诊断，具体可以看文档docs/superpowers/plans/2026-08-06-better-harness-fixes/00-plan.md

我们虽然支持推倒重建，如果把 Pi Agent 或者其他开源项目整体或部分移植效果更好于我们一条条修补，那我推荐直接移植。 现在请综合以上所有信息，然后裁断，下一步我们做什么、优化什么、怎么做，形成新的 PRD 文档和 SPEC 文档，直接取代旧文档。

对外定位

Anna 是面向小型团队协作的 2B Harness Agent。 它通过 MCP 接入现有业务系统，以 Crew 体系支持任务派办、评审、验收和人机接力，并通过 Chat、Cowork、Create 等工作界面承载沟通、业务查询与内容生产。 产品价值需要先讲清团队协作与业务执行，再说明 Harness 技术基础。 技术侧重点包括长程 Runtime、Trace、Memory、Tool、Skill、Eval、Sandbox 与恢复能力。 所有指标保持统一口径，产品结果、个人贡献、合作项目和待验证能力分别陈述。

发布前重构与公开发布

2026-08-07：第一次接入外部评测

8 月 6 日，我已经得出一个很重的判断：当时的 Anna 更接近堆叠起来的 Workflow，距离我期待的 Harness Agent 仍有明显差距。 继续围绕页面和局部 Bug 打补丁，很难验证长程任务、Trace、Memory、Tool、恢复和停止条件是否真的可靠。 8 月 7 日，项目完成了 Terminal-Bench 2.1 的 Anna headless 入口和 Harbor Adapter 接入。 Anna 可以用 JSONL 帧流进入外部评测链路。 这一步没有直接证明 Anna 已经拥有很强的任务能力，它先解决了一个更基础的问题：后续优化转向固定任务、统一入口、可重复运行和可检查证据，主观演示只作为补充。 当时形成的核心判断是：

  1. 跑通一个 Demo，只能证明某条链路曾经工作过。

  2. 任务、输入、ground truth、Trace、环境和版本需要一起冻结，结果才可复现。

  3. Silent failure 的成本很高。 一个看似成功、实际缺数据或走了假路径的结果，比明确报错更危险。

  4. 评测的目的在于暴露 Harness 问题，并将 Badcase 转成回归样本，分数只是结果之一。 这也是我第一次真正把“拒绝假数据和假演示”从产品原则变成工程验收要求。

2026-08-16：跨设备迁移与开发过程治理

Anna 最初在本机形成构想，之后迁移到 Computer 2 的 Windows 环境开发，又迁移到 Computer 3 继续修改，最终在 8 月 16 日前后回到 macOS。 本地同时保留了代码、外部资产、私有上下文、校验清单和迁移报告。 迁移让我发现，长项目的问题不只存在于代码里，也存在于开发过程本身：

  1. 不同设备可能各自保留不同版本，口头说“最新”没有意义。

  2. 代码、分支、Handoff、测试结果和未完成事项必须一起传递。

  3. AI Coding Session 会 Compact，上下文会腐烂，单个超长 Session 无法承担完整项目记忆。

  4. Git 需要成为代码事实来源，Handoff 需要成为任务事实来源，测试和 Trace 需要成为完成事实来源。 这次迁移为后续把 GitHub 作为长期版本管理中心埋下了伏笔。

2026-08-17：暂停 Crew，裁定 Harness v2 重构

回到 macOS 后，我先提出用 Claude Tag 的频道协作方式和 Buzz 的人机协作体验检查 Anna。 我希望确认 Anna 能否在一个真实团队场景中做到共享背景、持续学习、主动发现工作、异步执行和多人纠偏。 经过一轮判断，我确认了几项产品原则：

  1. 一个 Channel 只有一个 Anna。 频道成员共享同一个 Anna，Context 和 Memory 默认按频道隔离。

  2. 一个目标可以拆成多个并行 Run 或 Lane，由频道 Anna 统一协调。

  3. Crew 的方向保留，但阶段开发暂停。 底层 Harness 与 Agent Loop 成为瓶颈时，继续修 Crew 只会放大旧问题。

  4. Pi Agent 作为 Loop Kernel 参考和适配边界，Anna 自己负责 Event、Tool、Memory、Eval、Sandbox、权限和产品状态。

  5. 第一个真实闭环选择产品评审后的迭代开发：评审意见 → 决策提取 → PRD 修改 → UI 方案与截图 → 开发 Patch → 自动化测试 → Eval 与人工评审 → Merge-ready Candidate。 随后项目形成 Harness v2 Spec，并拆成 T00–T08。 T00 先冻结 Workspace、Channel、Session、Run、Artifact、Memory Candidate、RunProfile 等对象和接口；T01 再用固定版本的 Pi Agent Core 跑通最小 Loop Kernel Canary。 这个顺序帮助我理解，重构的起点是先讲清楚对象、边界、状态和证据，再进入代码实现。

2026-08-18：T02 Event Store 与运行事实持久化

T02 引入按 Workspace 和 Channel 隔离的 Event Store，并提供内存版与本地 SQLite 版。 对一个产品经理来说，这一步解决的问题可以这样理解：一次 Run 的开始、进展、工具调用、等待、失败和完成，都要成为有顺序、可恢复、可审计的事实。 进程退出后，事实仍然存在；重复命令不能制造第二次执行；一个 Run 只能拥有一个终态；页面展示可以从事件重新构建。 这一步让 Anna 从依赖某个在线进程的对话体验，走向拥有持久运行事实的 Agent Runtime 基础。

2026-08-19：T03 ToolGateway 与副作用治理

T03 完成 ToolGateway 主路径。 Pi 产生 Tool Call 后，需要经过 Tool 注册、Schema 校验、频道与角色范围、策略判断、必要审批、Sandbox 执行、副作用账本和结果事件，再返回给模型。 我在这一阶段特别关注两件事：

  1. Tool 能否执行与模型“想不想调用”分开。 真正的权限和副作用由 Harness 代码决定。

  2. 对外写操作必须可审计、可阻断、可去重。 结果未知时保持 unknown，不允许自动重放一次可能已经发生的外部操作。 同一天，我再次提出跨设备协同问题。 我的目标逐渐收敛为：Git 管代码版本，分支承载隔离开发，Handoff 传递上下文，固定点提交支持下一任务接管，GitHub 最终承担多端同步和公开版本维护。

2026-08-20：T04–T06 统一 Skill、Memory、Trace、Eval 与 Scheduler

8 月 20 日连续完成了三个基础阶段。

T04：Skills、RunProfile 与 Memory

Skill 从 SKILL.md 加载，带有版本、内容 Hash、来源以及允许和禁止的 Tool。 RunProfile 将模型、指令、Skill、Tool、预算、Memory 策略、Eval 和终止规则解析成不可变快照，避免一个正在运行的任务被静默换掉配置。 Memory 被拆成不同层次：Run Context 用于当前任务；Channel Memory 保存经确认的频道规则和决策；Workspace Memory 需要明确授权。 模型只能提出 Memory Candidate，频道 Owner 接受后才会进入长期 Memory。

T05：Trace 与 Eval

Run、Tool 和 Effect 事件被投影为 Trace。 缺失的 Token、成本和 Tool 结果保持缺失，不用 0 或推测值填补。 Eval 同时覆盖确定性的合同检查和版本化的质量评估，并建立 4 个 Smoke Case、16 个 Dev Case 以及失败 Trace 转 Regression Case 的路径。

T06：Scheduler 与 Fencing

Scheduler 支持显式计划、SLA、等待节点截止时间、Connector Event 和 Monitor Trigger。 它通过 owner-bound lease、heartbeat 和 started fence 限制重复执行。 这个设计回应了我早期对 Anna 主动性的期待，同时明确本地预览阶段的边界：应用关闭后不会持续运行，恢复需要显式触发。 到这里，Anna 的底层已经由“模型加工具”升级为包含状态、记忆、证据、预算、审批、调度和恢复边界的长期任务基础。

2026-08-21：建立可审计的 MVP Goal

我在 8 月 21 日提出两个阶段目标：先完成 Harness MVP 的基础开发与真实任务验证，再形成可以发布到 GitHub 的 Release Candidate。 缺失能力可以先审计 Codex 或 oh-my-pi，再做最小复用，避免继续凭空搭建一套新系统。 这一轮也暴露了开发方法上的严重问题。 大量任务挤在一个 Session 中，频繁 Compact 导致 Context Rot、重复劳动和错误接管。 我多次要求重新检查主目标、当前分支、固定点、任务边界和接管证据，并将工作拆到独立 Session 与 SubAgent。 从这一天起，项目的完成标准逐渐固定为：

  1. Wayfinder 和 Spec 先定义目标、范围与边界。

  2. Tickets 明确每一阶段只改什么、不能改什么。

  3. TDD 完整记录 Red → Green，并保留每个阶段的验证证据。

  4. Standards 与 Spec 分开复审。

  5. 必要时用真实浏览器或 Computer Use 检查用户侧行为，截图只用于高风险视觉与交互节点。

  6. Fixture、Fake Provider、Live Canary、Production Evidence 分层记录，任何一层通过都不能替代另一层。 我也开始归档已经完成历史使命的 T01–T07 Session。 开发过程本身第一次被当作需要治理的系统。

2026-08-22：明确真实证据缺口

发布审查告诉我，本地 Gate 和确定性测试已经覆盖很多合同，但真实 Bridge、Owner、Provider、MCP 和 Live Evidence 仍有缺口。 我没有接受“后续再补”这种模糊表达，而是继续追问：prompts、fixtures、ground truth 和 hash 具体是什么；Human Gate 为什么仍缺真实证据；Create、Cowork、Hub 的 v2 边界、WebSearch、Pi transcript restore 和 SSE reconnect 应该怎么修。 这一轮把证据分成了更清楚的层次：

  1. Fixture Evidence：合成输入与预期结果，适合稳定回归。

  2. Fake Provider Evidence：验证执行路径，不代表真实模型质量。

  3. Live Canary Evidence：真实 Provider 或真实连接器在受控场景中的运行证据。

  4. Production Evidence：真实产品 Runtime、真实权限、真实数据边界和真实用户流程。 T08 同期完成了本地 managed sidecar 的故障页、重启入口、preload 参数和 Runtime 生命周期恢复验证。 它证明了本地崩溃恢复切片可以工作，同时保留了真实外部 Provider、MCP 与完整生产切换尚未验证的结论。 这一天我学到，Creation is not verification。 Manifest 能证明文件完整，测试能证明合同覆盖，Live Canary 能证明一次真实链路，Production Readiness 仍需要独立证据。

2026-08-23：范围收敛为 Developer Preview

我提出，如果必须尽快发布到 GitHub，需要先判断完成度和阻塞项，然后以“尽快满足公开发布要求”为唯一 Goal，按 Wayfinder → Spec → Tickets → Implement → TDD 推进。 发布裁定保留了这些内容：

  1. Desktop Chat / Create、Cowork、Crew、Hub、Settings 与 Runtime 接管界面。

  2. Python Runtime 和可选开启的 Harness v2 Bridge。

  3. Durable Run / Event Store、ToolGateway、Memory Policy、Trace / Eval、Scheduler 和恢复基础。

  4. 合成 Fixture、验证脚本、公共文档、贡献与安全说明。 发布边界同时写明：这是 macOS Source Developer Preview；完整 Legacy → Harness v2 领域迁移、真实 Review-to-Validated-Patch、稳定外部 WebSearch / MCP、签名公证安装包和 Windows 发布验收仍是后续工作。 我也决定使用此前的 GitHub 仓库承载 Anna，并明确要求直接替换旧内容。 执行时先做备份、核对远端固定点，再使用带 lease 的更新方式。 8 月 23 日的首次远端替换遇到网络传输失败，因此当时没有把“本地候选已完成”写成“GitHub 已发布”。 这个失败被保留下来，直到远端分支和 Release 真正可验证。

2026-08-24：视觉收敛、服务诊断与 GitHub 发布

发布前，我又补回并重做了登录页。 新版采用 Anna 人物形象与左右结构，参考 Cofounder 的构图语言，同时保留 Iris 视觉、产品信息、主题切换与响应式布局。 我明确提出“形似，但不能完全一致”，也要求本地默认身份仍能看到登录界面，并预填测试账号。 登录页合入后，Crew 出现 /api/crew/* 404。 最终诊断发现，8000 端口运行的是只提供部分 Harness v2 路由的服务，完整 Crew Router 所在的 FastAPI 应用没有挂载。 这个案例再次证明，页面报错、端口存活和目标业务路由可用是三种不同事实。 最终发布审计覆盖 TypeScript、JavaScript、Python、前端 Smoke、Build、Evidence Manifest、依赖审计、macOS arm64 打包与 ASAR Smoke。 GitHub Release 记录的结果为 963 个 JavaScript / TypeScript 测试通过、7 个跳过，1048 个 Python 测试通过，并验证了 7 份 Evidence Manifest。 2026 年 8 月 24 日，Anna 以 v0.2.0 Developer Preview 发布，公共仓库确定为 Foxtailsss-Andy/Anna-Agent。 仓库随后成为代码、文档、版本标签和 Release 历史的公开事实来源。 公开材料中还补充了以下边界：

  1. Hiker 是合作伙伴 kc8zshnt6n-gif 开发的外部项目，目前没有开源。 Anna 仓库只包含 Anna 侧 Connector 与 UI Integration。

  2. Anna 使用 MIT License，授权范围不延伸到 Hiker 或其他未公开资产。

  3. 无 Provider 或 MCP 配置时，系统需要明确返回 not_configured，不能生成伪成功结果。

  4. v0.2.0 仍是 unsigned Developer Preview，公开源代码和本地验证通过不等于生产环境已经完成。

四次关键重构

回看整个过程，Anna 至少经历了四次方向明显的重构：

  1. 业务 Workflow 原型：从报销、财务看板、Hiker 和 Associate 场景验证 Anna 能否进入真实业务系统。

  2. Iris 前端与 Runtime 可视化：从表单堆叠走向 Chat / Cowork / Create，逐步增加流式过程、计划、产物、审批和 Trace 阅读体验。

  3. Crew 人机协作系统：将任务拆解、成员分派、频道沟通、Artifact、Review Gate 和交付状态放进同一个项目图。

  4. Harness v2：暂停表层功能扩张，用 Pi Loop Kernel、Event Store、ToolGateway、RunProfile、Memory、Trace / Eval、Scheduler 和恢复机制重新搭建可验证的运行基础。 这些重构没有把前面的探索全部否定。 报销与 Hiker 证明外部系统连接价值；Iris 证明 Agent 需要可理解的交互；Crew 证明团队协作需要任务、频道、产物和 Gate；Harness v2 则把这些产品能力放回可持久、可治理、可评测的执行系统中。

AI 产品经理的职责与贡献边界

我没有把自己的角色包装成独立完成所有代码的全栈工程师。 这份记录能够证明的个人工作主要包括：

  1. 从真实业务问题出发定义 Anna 的定位、用户、场景和产品边界。

  2. 在外部参考、代码现状和实际运行之间做取舍，先后决定暂停 Crew、引入 Pi、重写 Harness v2、收敛 Developer Preview。

  3. 把抽象目标拆成对象模型、Spec、Tickets、验收标准、失败分类和发布门禁。

  4. 持续发现交互、Runtime、Trace、Memory、权限、恢复、评测和开发协作中的问题，并要求形成可执行修复。

  5. 组织 AI Coding Agent 完成实现，使用测试、对抗性 Review、真实页面检查、Handoff 和固定点接管控制质量。

  6. 维护个人贡献、AI 实现、合作项目和未验证能力的边界，最终完成公开文档与版本发布。 对我而言，Vibe Coding 的价值在于让产品经理能够更直接地验证产品判断。 它仍然要求我学习专业术语、对象关系、运行时状态、失败模式和验收证据。 模型可以生成代码，产品方向、范围取舍、证据标准和发布责任仍然需要人来承担。

Developer Preview 发布边界

截至 v0.2.0 Developer Preview，以下内容继续作为后续工作：

  1. 完整的生产 Runtime 与 Harness v2 领域切换。

  2. 真实 Provider、WebSearch、MCP 与企业数据环境的可公开 Live Evidence。

  3. 完整 Review-to-Validated-Patch 生产审批链路。

  4. 签名与公证的 macOS 安装包。

  5. Windows 打包、安装与跨平台验收。

  6. Cowork、Crew、Hub 等领域在 Harness v2 上的完整迁移和长期稳定性验证。 保留这些缺口，是这份开发记录的一部分。 Anna 已经完成了第一次公开发布，也仍然处于可以继续学习、修正和迭代的阶段。

Anna

Clone this wiki locally