后台任务要有系统主体
一句话判断
Agent runtime 一旦开始承接 cron、队列、webhook 和夜间批任务，真正需要建模的就不再只是“哪个用户发起了这次对话”，而是“这个后台动作到底代表谁、拥有什么边界、如何被审计”。Mastra 在 6 月 12 日发布的 @mastra/core@1.42.0 把 trusted actor 显式接进 workflow、tool、memory 和 agent generate()/stream()，我觉得这是一个很重要的工程信号：后台任务不能再靠伪装成人类会话来获得权限，系统主体必须成为一等运行时对象。
背景：为什么这不是一个小 API
很多团队做 Agent 平台时，前台交互的权限模型往往比较清楚：有用户、有组织、有 thread、有审批。但一到后台任务就开始偷懒：
- 给定时任务塞一个假 JWT；
- 让队列消费者复用某个管理员用户；
- 或者直接绕过鉴权，在内部代码里“默认可信”。
短期看这很省事，长期会造成三个问题：
- 权限语义失真：日志上看起来像是某个真人用户做了操作，但其实是系统定时任务。
- 租户边界变脆：一旦后台作业不再带 tenant / organization 约束，就很容易把一个租户的工具、记忆或 workflow 跑到另一个租户上下文里。
- 恢复与审计困难：任务失败后，你很难回答“是谁触发的、为什么有权做、是否应该自动重试、结果该回到哪个线程”。
所以这里的核心不是“后台能不能调用 agent”，而是后台调用是否拥有一个和人类主体不同、但同样可验证、可约束、可追踪的主体模型。
核心机制：Mastra 这次到底做对了什么
1. 把 system actor 显式建模，而不是隐式放进上下文魔法里
Mastra 现在允许把一个 actor 对象显式传入：例如 actorKind: 'system'，并可附带 sourceWorkflow。这意味着后台任务不再需要伪装成某个用户 session，而是以“系统主体”的身份进入运行时。
这一步的意义很大：它把“后台动作也是一种主体”从约定俗成，提升成 API 合同。只要没有这个合同，系统内部就会不断出现“先借一个用户身份跑起来再说”的临时方案。
2. 它绕过的是 membership 解析，不是租户边界
这次设计里我最认可的一点，是 trusted actor 并不是全局免鉴权。Mastra 明确要求：即使是 system actor，requestContext 里仍然必须带 organizationId，否则 FGA bypass 会被拒绝。
这说明它想解决的问题不是“让后台任务变成超级管理员”，而是“让后台任务不必伪造人类 membership，同时仍然留在租户边界内”。
也就是说：
- 可以跳过“这个主体是不是某个组织成员”的人类式解析；
- 但不能跳过“这个动作属于哪个组织、在哪个权限域里执行”。
这个取舍非常关键。真正成熟的 Agent runtime，不应该把 trusted background job 设计成 root，而应该设计成tenant-scoped service principal。
3. 它把主体一直传到了 tool / memory / agent loop 里
很多框架即使入口层承认后台任务，到了执行深处仍然会丢身份：workflow 里还有，进 tool 就没了；agent 外层有，sub-agent 或 memory check 时又退化回普通上下文。
Mastra 这次是把 actor 连续穿过了几个关键边界：
workflow.execute()tool.execute()MastraMemory.checkThreadFGA()agent.generate()/stream()- agentic loop 内部的 tool-call 执行路径
这背后的工程价值是：主体如果不能跨 runtime boundary 传播，就不是真主体，只是入口注释。
对 OPC 这类系统来说，这一点尤其重要。因为真正容易串线的地方，恰恰不是最外层 HTTP 请求，而是第二层、第三层：子 agent、后台 workflow、异步工具、线程记忆、恢复执行。
4. 它还顺手把审计语义补齐了
PR 里还提到会把 actor_kind: "system"、sourceWorkflow 等信息打进 FGA telemetry。别小看这个细节——权限模型只有在 trace 和审计里可见，才算真正落地。
否则你虽然在代码里区分了 user actor 和 system actor，但排障时仍然只看到“某个调用失败了”，那运行时边界依然是黑箱。
对工程实践的启发
如果以后要让 Dewey / OPC 里的 Agent 承接日报汇总、定时评测、离线索引刷新、仓库巡检或自动修复，我会优先补这四层：
- 主体层：定义
user principal和system principal，不要让后台任务借人类身份运行。 - 租户层：即使是 system principal，也必须显式绑定 org / project / environment scope。
- 传播层：主体信息要穿过 workflow、tool、memory、sub-agent、resume path，而不是只停留在入口。
- 审计层：trace、审批记录、失败日志里必须能看出这是哪个 system actor、来自哪条 job/workflow。
这样做的直接收益是：以后当一个 cron job 写错数据、一个 repo bot 误开 PR、一个 nightly agent 扫错环境时，你至少能准确回答“它代表谁、为什么被允许、影响面在哪”。
常见误区
误区一：后台任务可信，所以直接给管理员权限
这通常是最快把系统做脆的方法。可信不等于无边界。后台任务比人类更应该被严格约束，因为它们执行频率高、自动化程度高、失败放大更快。
误区二：把 actor 放进共享上下文就行
如果主体只存在于某个可变 RequestContext 里，而没有被明确传入 workflow/tool/agent API，后续很容易在异步执行、重试、恢复和跨线程处理中丢失。主体要成为显式参数，才容易验证与审计。
误区三：有 system actor 之后就不需要审批
也不对。system actor 解决的是“谁在运行”和“如何授权”，不是“哪些高风险动作可以自动执行”。对外发消息、改生产配置、合并代码、执行 destructive tool，仍然应该保留审批或策略门。
我对这条信号的核心判断
Mastra 这次真正推进的，不是一个方便后台调用的 API，而是一个更成熟的 runtime 观念：前台的人类主体、后台的系统主体、租户边界和工具权限，应该被放进同一套运行时协议，而不是由开发者在不同模块里临时拼接。
对 Agent Engineer 来说，这意味着下一阶段的竞争点不只是模型效果，而是谁能更早把“系统主体 + capability + trace + approval”做成稳定基础设施。没有这层，Agent 很容易停留在 demo；有了这层，才开始像真正可托管的软件系统。
留给 Dewey 的问题
如果 OPC 下个月就要新增一个“夜间自动跑 repo 巡检并生成修复建议”的任务，你更愿意先固定哪一个：system principal 的 scope 模型，还是它的审批/回放模型？为什么？