[fasdwcx]

问题

cfg.Actor 未设置时，engram 用机器名造 actor（backend.go:129-136）。于是 agent 写的 conversation 挂在"某台机器"名下而不是人名下，用户在 MemoryLake 里按自己账号找不到自己的会话，而且每台机器都留下一个孤立 actor。

engram workspace 现状：35 个 actor 里 11 个是机器名型（Chuangxiandebijibendiannao.local、abruzz1deMacBook-Pro.local、VM-0-11-ubuntu …），24 个是 user::<id> 型。每个装了 engram 的人都踩着这个默认值。

改动

GET /api/v3/defaults/my-actor 只凭 bearer token 就能回答"这个 key 属于谁"。NewBackend 的 actor 解析改为三级，从最具体到最兜底：

顺序	来源	说明
1	cfg.Actor（ENGRAM_MEMORYLAKE_ACTOR / 配置文件）	显式设置继续优先，且完全跳过下面的查询
2	新增 /defaults/my-actor 的 custom_id	同时用其 display_name 作 actor 显示名，比把 user::<uuid> 当显示名可读
3	机器名 → engram	原样保留

第 2 步失败是正常结果而非错误：没有该端点的旧部署会落到第 3 步，因此不会对其产生回归。

仍然走 EnsureActor 而不是直接用端点返回的 id —— EnsureActor 尾部那步"绑定到 workspace 并容忍 BINDING_ALREADY_EXISTS"是必要的，用 id 直连会跳过绑定。

代价是 actor 未配置时每次构造 backend 多一次 GET，与本来就有的 ResolveWorkspaceID + EnsureActor 同量级。

真实环境验证（不只是 mock）

用已安装到 PATH 的新二进制、清空 actor 配置、打真实 MemoryLake：

$ engram turn --session engram-live-verify-20260826-153846 --transcript … --verbose
appended turn to conversation engram-live-verify-20260826-153846
  (message conv-entry-5239016322534ba3a29b50c573d80be4, 2642 bytes)
turn.log 行数不变（无新增失败）

$ # 服务端核对
conversation = conv-a32cc2ff19c248f18736335aee64684a
actor_ids    = ['actor-b6688f401b0e49eb99e0f7db8325cc41']
             = user::6345661e… / zhishu@zbyte-inc.com      ← 本人，而非机器名 actor

对照组：改动前同样在 actor 未配置下跑，归属是 actor-35f7a126…（Chuangxiandebijibendiannao.local）。

单元测试

internal/memorylake 新增 3 个用例（先红后绿）：

用例	断言
TestNewBackend_ActorFromMyActorEndpoint	未配置时用端点的 custom_id + display_name 建 actor
TestNewBackend_ConfiguredActorWinsOverMyActor	已配置时根本不请求该端点（handler 里直接 t.Fatalf）
TestNewBackend_FallsBackToHostnameWhenMyActorUnavailable	端点 404 / 返回空 两种子用例都回落到机器名

为什么改了 cmd/engram 的测试

新增的请求打破了 cmd/engram 里 10 个 routing 测试 + 1 个 turn 测试 —— 它们的 fake server 对未知路径 t.Fatalf。这些测试考的是后端选择与 turn 捕获，不是身份解析，所以统一钉上 ENGRAM_MEMORYLAKE_ACTOR（routing_test.go 用新增的 routingTestActor 常量，routing_cli_test.go 与 turn_test.go 走 env），既保持它们的关注点，也让它们以后不再受解析逻辑变化影响。

go test ./... 剩余 8 个失败与 git stash baseline 逐条相同（cmd/engram 2 个、plugin 5 个 + 1 个子用例），与本 PR 无关。go test -tags e2e ./internal/memorylake/ ./internal/server/ 全绿。

真机验证抓到一个回归，已在本 PR 内修掉

只跑 mock 测试不会发现：actor 一旦从机器名换开，所有在旧 actor 下建立的 conversation 都会永久追加失败。MemoryLake 会校验发送者是否为该会话的参与者：

append turn: memorylake INVALID_ARGUMENT (400):
  Actor 'actor-b6688f40…' is not a participant of this conversation

逐轮同步不重试，所以这不是一次抖动，而是那个会话余下所有轮次静默丢失（只在 turn.log 留一行）。是在本机检查真实 hook 路径时发现的 —— 当时这个 session 自己的 conversation 已经停在 4 条消息，失败在累积。

修法（fix(memorylake): append as a participant the conversation already has）：新增 senderFor —— 自己的 actor 在参与者列表里就用自己，否则用会话已有的参与者。这不损失任何东西：服务端本来就会把它自己的 per-conversation 参与者句柄盖在存下来的消息上；而新建的 conversation 仍带我们解析出的 actor，所以新会话照样归属到 key 所属用户。

两个新用例：TestAppendObservation_AppendsAsAnExistingParticipant（旧会话回落到已有参与者）、TestAppendObservation_KeepsOwnActorWhenItIsAParticipant（自己在列表里时不被覆盖）。

真机验证用的正是本 session 那个一直在失败的 conversation：恢复追加，消息数 4 → 5，turn.log 无新增。

发布

本分支含 feat:，按 SemVer 走 minor → v0.7.0，三个插件清单已一并 bump（chore(release)），否则 release.yml 的校验会在 GoReleaser 之前拦下发布。

范围外

消息级的 actor_id 不在本 PR 范围：新旧 conversation 的消息 actor 是两个不同 id 且 GET /api/v3/actors/{id} 均返回 NOT_FOUND，而真实 actor 查得到 —— 那是服务端按 conversation 派生的内部参与者句柄，engram 无从控制。本 PR 只涉及 conversation 级归属。

Closes #22