@jun133/athlete 0.0.5 → 0.0.7

package/spec/modules/tool-registry.md

@@ -1,137 +0,0 @@
-# tool registry
-
-## 作用
-
-Tool registry 负责向模型公开动作集合，并统一管理本地工具与 MCP 动态工具。
-
-## 当前组成
-
-- 本地内建工具
-- mode 过滤后的工具集
-- MCP 动态收集到的工具
-- 统一治理后的 `entries / blocked` 结果
-
-## 当前规则
-
-1. 新工具先注册，再暴露给模型。
-2. tool handler 只做动作，不做控制面真相发明。
-3. skill 不是工具替代品；skill 提供 workflow，tool 提供动作。
-4. MCP 工具也必须经过统一 registry，不走旁路。
-5. 工具暴露顺序、workflow fallback、change / verification signal 约束都由机器治理 metadata 决定，而不是靠 prompt 复述。
-6. metadata 缺失或不兼容时默认 fail-closed：
-   - 内建 / 本地 includeTools 直接报错
-   - MCP 工具进入 `blocked`，不暴露给模型
-
-## 工具层职责
-
-`src/tools/` 当前负责：
-
-- 参数解析
-- 权限和状态校验
-- 调用下层 store / worker / utils
-- 把结果序列化返回给模型
-
-不负责：
-
-- provider 请求
-- session 存储
-- 发明新的持久化真相
-
-## 当前分组
-
-- `src/tools/files/`
-- `src/tools/documents/`
-- `src/tools/tasks/`
-- `src/tools/team/`
-- `src/tools/worktrees/`
-- `src/tools/background/`
-- `src/tools/shell/`
-- `src/tools/skills/`
-
-共享层仍在 `src/tools/` 根目录：
-
-- `registry.ts`
-- `runtimeRegistry.ts`
-- `governance.ts`
-- `routing.ts`
-- `shared.ts`
-- `types.ts`
-- `changeTracking.ts`
-
-## Playwright MCP 当前事实
-
-当前 Playwright adapter 通过 runtime registry 暴露一组 `mcp_playwright_browser_*` 工具；这是 adapter surface，不是上层 machine rule。
-
-当前 adapter 层常见名字包括：
-
-- `mcp_playwright_browser_navigate`
-- `mcp_playwright_browser_snapshot`
-- `mcp_playwright_browser_click`
-- `mcp_playwright_browser_type`
-- `mcp_playwright_browser_take_screenshot`
-- 以及其他 `mcp_playwright_browser_*`
-
-当前优先级策略：
-
-- runtime registry 先用治理 metadata 做 fail-closed 过滤，再按机器排序暴露工具
-- 浏览器工具会通过治理 metadata 稳定排到本地文件工具和 shell 工具前面
-- request 级 tool priority 会消费同一套 metadata，在 web research / browser automation 场景继续把浏览器 capability 工具前置
-- `run_shell` 与本地文件 detour 在 browser workflow 下只作为 fallback
-
-## 当前治理模型
-
-当前 registry 暴露给机器的不只是 tool schema，还包括：
-
-- `entries`: 每个已暴露工具的统一 governance metadata
-- `blocked`: 因 metadata 缺失、MCP 缺少可信只读提示、或治理不兼容而被 fail-closed 的工具
-
-当前 governance metadata 至少回答：
-
-- 是否只读 / 会不会修改状态
-- 是否高风险 / destructive
-- 是否要求 change signal / verification signal
-- 是否属于 browser capability
-- browser step 是 `navigate / snapshot / take_screenshot / click / type / other`
-- 是否属于 document-reading capability
-- document kind 是 `doc / image / pdf / ppt / spreadsheet`
-- 是否在特定 workflow 下只能 fallback
-- 是否并发安全
-
-## 当前上层约束
-
-上层 machine rule 当前必须遵守：
-
-1. workflow guard 只认 browser capability / browser step，不认具体 Playwright 工具名。
-2. tool priority 只认治理 metadata，不认具体 Playwright 工具名。
-3. document routing hint 只认 `document.read` / `spreadsheet.read` capability，不把 `mineru_*` 名字继续上推。
-4. acceptance / phase / verification 只认统一 signal，不认 adapter 工具名。
-
-## 当前代码落点
-
-- `src/tools/governance.ts`
-  - browser capability、browser step、document kind、fail-closed metadata
-- `src/tools/order.ts`
-  - 暴露排序
-- `src/agent/toolPriority.ts`
-  - request 级 tool priority，消费统一 metadata
-- `src/skills/workflowGuards.ts`
-  - 只输出 `suggestedCapability`
-- `src/tools/routing.ts`
-  - `document.read` / `spreadsheet.read` capability hint
-- `src/mcp/toolAdapter.ts`
-  - adapter 层把 MCP 工具接入 registry，保留 origin 信息
-
-## 对齐说明
-
-- adapter 层仍可以保留 `mcp_playwright_browser_*`、`mineru_*` 这类生态名词
-- 但 registry 暴露给上层的真相必须是 capability metadata，而不是生态字符串
-
-## 当前约束
-
-如果某个动作：
-
-- 需要明确输入输出
-- 不适合塞进 prompt
-- 不该让模型自己拼 shell
-
-就应该做成工具，而不是继续加提示词。

package/spec/modules/weixin-private-chat.md

@@ -1,291 +0,0 @@
-# Weixin 私聊接入
-
-## 范围
-
-- 只支持 Weixin 私聊
-- 不支持群聊、频道式广播、多平台网关
-- 不做 `weixin-acp` / `codex-acp` / 外部子进程 agent 桥接
-- 只做 Weixin 通道层能力扩展，不重写 Athlete 核心 runtime
-
-## 宪法对齐
-
-这块实现必须遵守 `spec/principles/` 里的核心原则：
-
-- `P01 一个循环一个智能体`
-  Weixin 只是把私聊消息接到现有 lead turn，不重写 agent loop
-- `P16 配置只能有一个入口`
-  Weixin 配置统一走 `src/config/store.ts` 和 `.athlete/.env`
-- `P17 扩展靠事件生长`
-  Weixin 通道通过边界模块、turn display、store、delivery queue 生长，不把平台细节塞进核心 runtime
-- `P18 主循环和文件都不能长胖`
-  Weixin 服务编排、turn 执行、附件处理、日志、命令语义、CLI 按职责拆模块
-- `P19 先写失败测试再写实现`
-  Weixin 配置、store、delivery、service、CLI、文档入口都有 fail-first 测试保护
-
-## 模块边界
-
-Weixin 相关实现集中在 `src/weixin/`：
-
-- `types.ts`
-  OpeniLink message shape 的 Athlete 规范化类型
-- `config.ts`
-  Weixin 配置默认值、归一化、运行时状态目录解析
-- `client.ts`
-  OpeniLink SDK 的 Athlete-native 包装层
-- `polling.ts`
-  long polling 和 `sync_buf` 提交
-- `syncBufStore.ts`
-  Weixin 拉取游标持久化
-- `credentialsStore.ts`
-  登录态持久化
-- `sessionMapStore.ts`
-  Weixin peer 到 Athlete session 的绑定
-- `attachmentStore.ts`
-  入站附件元数据持久化
-- `contextTokenStore.ts`
-  每个 peer 最新 `context_token` 的持久化、刷新、失效标记
-- `deliveryQueue.ts`
-  文本 / 图片 / 视频 / 文件投递队列、重试、恢复、`context_token` fail-closed
-- `messageClassifier.ts`
-  private-only 路由和消息类型判定
-- `inboundFiles.ts`
-  入站媒体下载、落盘、turn input 构造
-- `localCommands.ts`
-  Weixin 端命令语义适配
-- `outputPort.ts`
-  Weixin 文本输出适配
-- `turnDisplay.ts`
-  Weixin 过程输出适配
-- `turnRunner.ts`
-  单个 Weixin turn 的运行编排
-- `service.ts`
-  Weixin 服务总控、拉取、分发、stop、恢复
-- `logger.ts`
-  终端高层日志
-- `processLock.ts`
-  Weixin 服务单实例锁
-- `cli.ts`
-  `login / serve / logout` 正式命令入口
-- `sendFileTool.ts`
-  Weixin 出站媒体工具桥
-
-CLI 注入仍然放在：
-
-- `src/weixin/cli.ts`
-- `src/cli.ts`
-
-## 启动方式
-
-命令：
-
-```powershell
-athlete weixin login
-athlete weixin serve
-athlete weixin logout
-```
-
-行为：
-
-1. `login` 通过 OpeniLink QR 登录并保存登录态
-2. `serve` 读取统一配置入口和项目状态目录
-3. 获取 Weixin 单实例锁
-4. 启动 long polling
-5. 把私聊消息接入现有 Athlete session / turn 体系
-6. 把文本和媒体回复先落到 delivery queue，再尝试发送
-7. `logout` 清理登录态、`sync_buf` 和 token 相关发送状态
-
-默认交互模式不会被劫持；只有显式执行 `athlete weixin ...` 才会启动 Weixin 通道。
-
-## 配置
-
-Weixin 配置统一并入 `AppConfig.weixin` / `RuntimeConfig.weixin`。
-
-推荐通过 `.athlete/.env` 配置：
-
-```text
-ATHLETE_WEIXIN_ALLOWED_USER_IDS=wxid_alice,wxid_bob
-ATHLETE_WEIXIN_BASE_URL=https://ilinkai.weixin.qq.com
-ATHLETE_WEIXIN_CDN_BASE_URL=https://novac2c.cdn.weixin.qq.com/c2c
-ATHLETE_WEIXIN_POLLING_TIMEOUT_MS=30000
-ATHLETE_WEIXIN_POLLING_RETRY_BACKOFF_MS=1000
-ATHLETE_WEIXIN_MESSAGE_CHUNK_CHARS=3500
-ATHLETE_WEIXIN_TYPING_INTERVAL_MS=4000
-ATHLETE_WEIXIN_QR_TIMEOUT_MS=480000
-ATHLETE_WEIXIN_DELIVERY_MAX_RETRIES=6
-ATHLETE_WEIXIN_DELIVERY_BASE_DELAY_MS=1000
-ATHLETE_WEIXIN_DELIVERY_MAX_DELAY_MS=30000
-ATHLETE_WEIXIN_ROUTE_TAG=
-```
-
-说明：
-
-- `ATHLETE_WEIXIN_ALLOWED_USER_IDS` 必须显式配置；空白名单等于任何人都不能控制
-- Weixin 配置仍然只走同一套配置入口，不另起平行配置系统
-- 登录态不放进配置文件，而是放在项目状态目录下的 `credentials.json`
-
-## 单实例语义
-
-Weixin 服务必须是单实例：
-
-- 同一个项目状态目录下，只允许一个 `weixin serve`
-- 如果已经有一个存活实例，第二个实例直接拒绝启动
-- 如果只剩下陈旧 `service.pid`，新实例会识别为 stale lock 并自动覆盖
-
-这样可以避免：
-
-- 同一条消息被两个实例重复消费
-- 同一条回复被重复发送
-- 用户误以为服务已经退出但实际上还有旧实例在线
-
-## 状态与恢复
-
-Weixin 状态目录位于：
-
-```text
-<project-state-root>/.athlete/weixin/
-```
-
-持久化内容包括：
-
-- `credentials.json`
-  扫码登录态
-- `sync-buf.json`
-  下一个拉取游标
-- `session-map.json`
-  `weixin:private:<userId>` 到 Athlete session 的映射
-- `attachments.json`
-  入站图片 / 视频 / 文件 / 语音元数据和本地落盘路径
-- `context-token.json`
-  每个 peer 最新可用的 `context_token`
-- `delivery.json`
-  待发送文本 / 图片 / 视频 / 文件、重试次数、阻塞原因
-- `service.pid`
-  Weixin 单实例锁
-
-恢复语义：
-
-1. 重启后先恢复 `sync_buf`
-2. `session-map.json` 恢复同一 Weixin 私聊到同一个 Athlete session
-3. `delivery.json` 在启动和轮询前后都会扫描并补发
-4. `attachments.json` 让“刚发的文件 / 图片 / 语音”这类语义可继续工作
-5. `context-token.json` 决定哪些待发送项现在可投递，哪些必须继续保留
-
-## `context_token` 限制
-
-`context_token` 是 Weixin 通道的硬边界。
-
-Athlete 当前正式语义：
-
-- 每次入站消息都会捕获并更新当前 peer 可用的 `context_token`
-- 所有出站文本 / 图片 / 视频 / 文件都必须使用当前 token
-- delivery queue 会显式区分：
-  - `missing_context_token`
-  - `context_token_invalid`
-- 如果服务重启后队列里还有待发送项，但 token 缺失或失效：
-  - 不丢消息
-  - 不误报成功
-  - 不 silent failure
-- 待发送项会保留
-- 只有等这个 peer 下次再发新消息、token 刷新后，队列才会再次尝试投递
-
-这是 Weixin 和 Telegram 最关键的运行差异之一，README 和测试都必须同时体现。
-
-## 文件能力
-
-### 入站媒体
-
-- 支持图片、视频、文件、语音入站
-- OpeniLink 下载后的本地文件会进入当前 turn input 和附件上下文
-- 语音通过 OpeniLink 提供的下载 / 解码入口落成本地 WAV
-- 附件元数据会写入 `attachments.json`
-
-### 出站媒体
-
-- 支持文本、图片、视频、文件出站
-- 工具桥会根据文件类型做真实路由
-- 不支持“只回复一个本地路径”这种伪文件发送
-- 不支持语音回发；该能力因为上游没有稳定发送接口而 fail-closed 拒绝
-
-## `/stop`
-
-Weixin 端只保留一个停止命令：
-
-```text
-/stop
-```
-
-语义：
-
-- 只停止“当前这个 Weixin 用户当前正在执行的任务”
-- 服务继续在线
-- 不影响其他白名单用户
-- 当前任务停止后，这个用户还能继续发下一条任务
-
-## 命令语义
-
-Weixin 端命令语义与本地 CLI 有明确边界：
-
-- `/session`、`/config`、`/runtime` 等查看类命令继续复用现有本地命令层
-- `/multi` 明确拒绝，并提示直接发送完整消息
-- `quit` / `reset` / `/reset` 只做提示，不执行本地终端语义
-
-## 过程输出
-
-Weixin 过程输出保持聊天式，但优先保证“最终结果稳定可见”，不刷底层噪音。
-
-聊天框里的可见消息：
-
-- `todo_write` 对应的可见 preview 一次，就发一条 todo preview 消息
-- `onAssistantDelta` 只作为阶段内缓冲信号，不直接发聊天消息
-- `onAssistantText` 表示拿到了完整 assistant 文本时，发一条 assistant 消息
-- `onAssistantDone` 带文本且当前 assistant 阶段尚未发出时，发一条最终 assistant 消息
-- 不合并多段 assistant
-- Weixin 不再发送 tool call 聊天消息，避免挤占最终回复的可见额度
-- 短回复走普通文本；长回复超过阈值时直接写成 `.txt` 文件并作为文件发送
-- 不把 todo / assistant 混成一条
-
-不发送：
-
-- tool call
-- 工具输出正文
-- 大段文件原文
-- 底层噪音日志
-- reasoning
-- `onStatus` 一类非可见噪音
-
-终端日志持续输出高层事件：
-
-- 收到哪个 Weixin 用户的消息
-- 当前进入哪个 session
-- 当前阶段、工具、成功 / 失败 / 停止
-- 当前是否发送了文本或媒体
-
-显式信号与可靠性约束：
-
-- Weixin / Telegram 共享同一层可见事件判定与 durable turn display
-- durable outbound 只按事件顺序发送，不按文本去重
-- 如果要防重复，只能基于 event id / delivery state，不能基于文本内容
-- `runOnce` 必须等当前 turn 的可见输出 durable 完成后再 commit 输入
-- `serve` 主循环通过显式 pending-commit 队列继续轮询和处理 `/stop`，不靠时序猜测
-- 可见消息 durable enqueue 失败不能 silent swallow，必须继续上抛
-
-## 串行与隔离
-
-- 同一 Weixin peer 使用 per-peer queue 串行执行
-- 不同 peer 之间允许并发
-- `/stop` 与 per-peer 串行队列兼容
-- 同一个 peer 的 turn 不能并发破坏同一个 session
-
-## 安全与约束
-
-- 只接受 `allowedUserIds` 白名单内的私聊用户
-- 非白名单用户不会进入 Athlete turn
-- 群聊消息不会进入 session
-- Weixin 端仍然遵守 Athlete 当前 runtime 的 `mode`、`allowedRoots` 和执行约束
-
-## 非目标 / fail-closed 边界
-
-- 不做 `weixin-acp` / `codex-acp` 子进程桥接
-- 不做群聊路由投机实现
-- 不伪造语音回发能力
-- 不在 `src/agent/`、`src/tools/`、`src/ui/` 里散落平台特有分支

package/spec/modules/workspace-isolation.md

@@ -1,24 +0,0 @@
-# workspace / isolation
-
-## 作用
-
-工作区隔离负责避免并行任务互相污染。
-
-## 当前能力
-
-- allowed roots
-- task 与 worktree 绑定
-- worktree 创建、保留、删除
-
-## 规则
-
-1. 共享根目录适合读和轻量改动。
-2. 并行改动优先进入独立 worktree。
-3. task 是逻辑隔离，worktree 是目录隔离，两者不能混为一谈。
-
-## 下一阶段要求
-
-总指挥层需要会判断：
-
-- 什么时候共享目录就够了
-- 什么时候必须派到独立 worktree

package/spec/modules//346/211/251/345/261/225/346/234/272/345/210/266.md

@@ -1,141 +0,0 @@
-# 扩展机制
-
-## 当前扩展口
-
-Athlete 当前有 3 个标准扩展口：
-
-1. tools：负责动作
-2. skills：负责按需 workflow 与知识
-3. MCP：负责接外部能力源
-
-## skill 当前状态
-
-skills 已经是标准化 V1，而不是散装 prompt 片段。
-
-当前主要实现：
-
-- `src/skills/types.ts`
-- `src/skills/schema.ts`
-- `src/skills/discovery.ts`
-- `src/skills/matching.ts`
-- `src/skills/loading.ts`
-- `src/skills/state.ts`
-- `src/skills/workflowGuards.ts`
-- `src/skills/prompt.ts`
-
-## 当前 workflow skill
-
-当前仓库已落地的关键 workflow skill：
-
-- `test-guardrails`
-- `spec-alignment`
-- `mineru-pdf-reading`
-- `mineru-image-reading`
-- `mineru-doc-reading`
-- `mineru-ppt-reading`
-- `web-research`
-- `browser-automation`
-
-MinerU 文档 workflow 现在按类别拆成独立工具：
-
-- `mineru_pdf_read`
-- `mineru_image_read`
-- `mineru_doc_read`
-- `mineru_ppt_read`
-
-## web-research / browser-automation 的边界
-
-这两个 skill 现在已经是真实 workflow，而不是占位文档。
-
-职责边界：
-
-- `web-research`
-  - 何时先搜
-  - 何时打开网页
-  - 何时提取信息
-  - 何时总结
-  - 何时落文档
-- `browser-automation`
-  - 何时导航
-  - 何时 snapshot
-  - 何时 click / type
-  - 何时 screenshot
-  - 何时做网页交互
-
-不负责：
-
-- 实现浏览器 transport
-- 取代 MCP / tool
-
-## 联网能力分层
-
-当前分层是：
-
-1. MCP / tools
-   - 提供真实浏览器能力
-   - 当前优先是官方 `@playwright/mcp`
-2. workflow skill
-   - 提供使用策略
-   - 当前是 `web-research` 与 `browser-automation`
-
-设计原则：
-
-- 联网能力先做成 `tool` 或 `MCP`
-- `skill` 只做 workflow
-- 不把底层联网继续堆进 `systemPrompt`
-
-## 当前 capability 边界
-
-当前扩展层已经明确区分：
-
-1. adapter / tool surface
-   - 可以保留 `@playwright/mcp`、`mineru_*` 这类生态名词
-2. runtime governance / workflow / acceptance
-   - 只认 capability / signal
-   - 不认具体生态字符串
-
-当前上层抽象：
-
-- browser capability
-  - `browser.navigate`
-  - `browser.snapshot`
-  - `browser.take_screenshot`
-  - `browser.click`
-  - `browser.type`
-- document capability
-  - `document.read`
-  - `spreadsheet.read`
-- acceptance signals
-  - `http_endpoint_verified`
-  - `web_page_verified`
-  - `document_read_completed`
-  - `structured_artifact_valid`
-
-## 当前接线点
-
-当前 skill / MCP / runtime 的接线点：
-
-- `src/context/projectContext.ts`
-- `src/tools/skills/loadSkillTool.ts`
-- `src/agent/systemPrompt.ts`
-- `src/skills/prompt.ts`
-- `src/agent/runTurn.ts`
-- `src/tools/governance.ts`
-- `src/tools/runtimeRegistry.ts`
-- `src/tools/routing.ts`
-- `src/mcp/registryIntegration.ts`
-- `src/mcp/toolAdapter.ts`
-- `src/agent/acceptance/signals.ts`
-
-## 当前约束
-
-当前扩展仍必须满足：
-
-- 不破坏 continuation / compact / recovery
-- 不让主循环继续长胖
-- 不新造平行技能体系
-- 不让 MCP 绕开统一 registry
-- skill prompt 只输出本轮决策相关的 runtime hint（loaded / selected / missing required），不回退成 catalog dump
-- MCP 工具进入 runtime registry 前必须先经过治理 metadata 归一化；安全信息不够时默认 fail-closed
-- browser-first / document routing / workflow fallback 由机器治理逻辑优先决定，prompt 只保留原则级说明
-- adapter 名词允许存在于工具实现、技能名、README、配置与测试中，但不允许继续进入上层 machine rule

package/spec/overview/v0/350/214/203/345/233/264.md

@@ -1,55 +0,0 @@
-# v0 范围
-
-## 当前已在范围内
-
-### 运行时
-
-- 单 turn 主循环
-- 自动 continuation
-- 上下文压缩
-- verification 状态机
-
-### 工具与执行
-
-- 文件读写与补丁修改
-- shell 执行
-- docx / spreadsheet 基础能力
-- background job
-
-### 控制面
-
-- 任务板持久化
-- machine-enforced orchestration lifecycle
-- teammate 名册与 inbox
-- 协议请求与审批状态
-- worktree 绑定与隔离
-
-### 扩展
-
-- 项目指令发现
-- skill catalog 发现与按需加载
-- MCP 工具接入
-
-## 当前不在范围内
-
-- 图形化编排平台
-- 跨项目长期人格记忆
-- 全自动自治 swarm
-- 复杂经济系统、积分系统、市场化调度
-- 大而全行业平台能力
-
-## 下一阶段新增范围
-
-1. 主 Agent 的总指挥层
-2. 更清晰的任务拆分与派工规则
-3. skills 的标准声明与加载协议
-4. reviewer / verifier / planner 这类专门角色的演进边界
-
-## 范围控制规则
-
-如果一个新需求同时满足下面两条，应该延后：
-
-- 会削弱当前“耐跑底盘”
-- 不能明显增强“总指挥层”或 “skills 扩展口”
-
-当前阶段优先做“更会组织”，不是“看起来更全能”。

package/spec/overview//344/272/247/345/223/201/345/256/232/344/271/211.md

@@ -1,61 +0,0 @@
-# 产品定义
-
-## Athlete 是什么
-
-Athlete 是一个终端优先的 AI harness。
-
-它不是“在命令行里聊天”，而是一套让模型持续做任务的运行系统：
-
-- 能调用工具
-- 能持久化任务状态
-- 能续跑长任务
-- 能把慢操作放后台
-- 能按需调用子智能体或队友
-
-## 当前核心定位
-
-当前 Athlete 的核心定位是：
-
-**一个耐跑、可续跑、面向复杂任务的终端智能体框架。**
-
-它现在最强的价值不是“最会聊天”，而是：
-
-- 不容易中途断掉
-- 出错后会继续排查
-- 长任务能自动续跑
-- 多步任务有状态落盘
-- 任务派工和恢复不靠 prompt 记忆
-
-## 下一阶段定位
-
-下一阶段 Athlete 的定位是：
-
-**一个以耐跑主 Agent 为核心、能够统筹任务与技能扩展的总指挥型智能体平台。**
-
-关键词：
-
-- 主 Agent 很强
-- 复杂任务时会拆分与调度
-- skills 是标准扩展口
-- 多 Agent 是按需能力，不是默认军团
-- 控制面知道任务为什么 ready / blocked / active / completed
-
-## 目标用户
-
-### 当前主要用户
-
-- 会在终端里工作的开发者
-- 想研究 agent harness 架构的维护者
-
-### 未来扩展用户
-
-- 需要多步自动化的人
-- 需要文档、表格、资料整理等复杂任务的人
-- 想给 agent 增加行业技能的人
-
-## 非目标
-
-- 不做拖拽式工作流平台
-- 不做纯聊天机器人
-- 不追求“默认一堆 agent 同时乱跑”
-- 不把长期人格记忆作为当前阶段的核心卖点