fak：Fused Agent Kernel 与 managed-agent 控制面

fak：Fused Agent Kernel 与 managed-agent 控制面

为什么重要

fak 把“工具型 agent”包装成 managed agent：模型接口保留，但外部 kernel 拥有 model traffic/cache、context lifetime、capabilities 和 recovery。它的最小 proof 是离线 deterministic run：任务完成，同时 poisoned tool result 被拦截、destructive operation 被阻止。对 Hermes 来说，这是 Harness-Engineering 的一个清晰抽象：控制层不必替换模型，而是在模型与世界之间拥有 syscall-like 边界。

机制 / 一阶原理

fak 使用 kernel 隐喻组织 agent runtime：in-syscall repair 处理 malformed tool call，vDSO-like cache 复用重复调用，adjudicator 在执行前拒绝危险调用，MMU quarantine 把不可信工具结果隔离出模型上下文。关键原则是：让 agent 继续完成任务，同时在 effect/context boundary 处执行确定性控制，而不是让模型自己既行动又监管。

与现有 wiki 的关系

它与 redstamp-deterministic-agent-firewall、agentlint-runtime-guardrails、nemo-relay-agent-runtime-control 都在讲 runtime 控制；fak 的差异是把 cache、context lifetime、capability 和 recovery 合成一个 managed-agent kernel。它也和 agentfootprint-explainable-agent-traces互补：fak 控制事件，AgentFootprint 解释事件因果。

可执行启发

• Hermes 可把高风险工具调用分成 syscall-like categories：读、写、网络、凭证、子代理、发布，并给每类默认 adjudicator。
• 不可信 tool output 不应默认进入长上下文；应先 quarantine、摘要、检查 injection，再决定是否暴露给模型。
• 对无人 cron，离线 deterministic proof 比 live demo 更有价值：可重复证明 policy boundary 和 recovery path。

失败模式 / 边界

kernel 抽象容易过度命名：如果没有真实 policy、隔离和恢复证据，只是包装 CLI。离线 mock proof 也不能证明真实模型质量、真实延迟或复杂生产权限下的安全性；它证明的是控制路径可执行，而不是所有场景可靠。

写入记录

• 2026-08-05 09:00 CST：新增 fak 来源页，聚焦 managed-agent kernel、tool result quarantine 和 syscall-like control boundary。