AgentMesh Runtime Gateway：task envelope 到 sandbox/telemetry receipt 的最小控制面

wiki/ai/sources/agentmesh-runtime-gateway-task-envelope-sandboxclaim.md

分类：ai / sources · 更新：2026-09-10 12:06

AgentMesh Runtime Gateway：task envelope 到 sandbox/telemetry receipt 的最小控制面

一句话结论

AgentMesh Runtime Gateway 是一个小型 reference kernel：它把一个 agent task 先规范化成 versioned task envelope，再按 capability authority、data classification、tenant trust、mutation impact、budget 与 runtime isolation 生成执行计划、Kubernetes SandboxClaim、OpenTelemetry-shaped event 和 deterministic receipt。它的价值不在“又一个 MCP/A2A gateway”，而在把 agent runtime 的控制面压缩成可测试的最小合同。

命中的知识点轴

MCP Gateway / federation control plane：README 明确把 Codex/Claude Code/OpenCode、LangGraph/CrewAI/n8n、MCP tools、A2A agents、Kubernetes sandbox 与云基础设施放到同一个 portable execution plan 下。
A2A / Agent Card / Agent Discovery：代码中的 AgentCard 更接近内部 agent registry 条目，提示 A2A Card 的公开发现信息进入生产前还需要 capability/data/runtime 约束。
harness-runtime：把“能否执行”拆成 pre-execution planning，而不是让 agent 直接调用 Terraform、GitHub、browser 等工具。
benchmark-evaluation：tests/test_planner.py 覆盖 approval、deny、budget、raw context rejection、deterministic receipt 与 bundle 输出，说明 runtime policy 可以被单元测试。
sandbox-security：runtime profile 在 rootless container、Kata microVM、dedicated VM sandbox 间选择，并把 restricted / untrusted / production mutation 路由到更强隔离。

为什么对用户重要

对 Hermes / llm-wiki 来说，这个项目补上了最近几天 gateway/trust receipt 讨论中的一个缺口：很多页面强调 policy、approval、Agent Card 或 audit，但 AgentMesh 展示了一个更前置的步骤——先把任务转成结构化 envelope，并在执行前做 agent 选择、runtime placement、预算与权限判定。没有这个 envelope，gateway 容易只看到孤立工具调用，难以判断它属于哪个任务、需要哪类隔离、是否涉及生产变更、是否超过预算。

这对无人 cron 和 agentic coding 尤其重要。比如“准备 Azure Terraform 变更”并不等于允许 terraform.apply 或 github.merge；AgentMesh 的示例把 terraform.plan、checkov.scan、infracost.estimate、github.pull_request.create 放行，把 terraform.apply 与 browser.write 标成 approval，把 github.merge deny，并为 restricted / untrusted multi-tenant / production mutation 选择 dedicated VM sandbox。这个设计可以直接迁移成 Hermes job policy：雷达任务、wiki ingest、CVM 发布、代码修改、生产部署应有不同 task envelope 和 runtime profile。

机制 / 一阶原理

AgentMesh 的核心机制是 task envelope → plan receipt。输入中显式包含 requested_capabilities、context_refs、data_classification、tenant_trust、mutation_impact、maximum_cost_usd、deadline_seconds、idempotency_key 与 evidence_required。planner 先 fail-closed 拒绝未知 capability，再筛选满足 capability 与 data level 的 agent，再筛选满足数据级别、untrusted tenant、production mutation 与 workload identity 的 runtime，最后按预算给出 ready / require_approval / denied 决策。

第二个机制是 runtime placement as policy。rootless-container、kata-microvm-sandbox、dedicated-vm-sandbox 不只是部署选项，而是权限、租户信任和生产变更风险的函数。相比只在 MCP gateway 上做 allow-list，这种 placement policy 更接近 [[aisi-sandboxescape-bench-container-breakout Sandbox / security evaluation]] 要求的 harness contract：必须记录 runtime class、隔离边界、workload identity 和是否允许 production mutation。

第三个机制是 receipt bundle。项目会输出 task-envelope.json、decision.json、otel-event.json、sandboxclaim.yaml 和 report.md；decision 中包含 receipt_sha256，otel-event 包含 agentmesh.evidence.receipt。这不是证明外部操作真的完成的强 receipt，但它明确区分了“计划被 deterministic policy 判定过”和“真实 sandbox 已 provision / 外部动作已执行”。这种诚实边界比很多 agent 报告更可靠。

和已有 wiki 概念的关系

MCP-Gateway-Runtime 负责能力与策略入口，Harness-Engineering 负责将任务约束落实为工具面和执行环境；本项目的规划回执连接二者，但不能替代真实执行与外部状态验证。

- 相比 [[aegisflow-local-first-policy-gateway	AegisFlow]]，AgentMesh 更偏 task-level planning 与 runtime placement；AegisFlow 更偏 action-level interception、review-resume 与 signed evidence chain。两者合起来形成 task envelope + action envelope 的双层控制面。
- 相比 [[permit-mcp-gateway-enterprise-trust-layer	Permit MCP Gateway]]，AgentMesh 没有展示企业级 human identity / consent UI，但把 data classification、tenant trust、mutation impact、budget 与 runtime class 放进了最小 planner。
- 相比 [[a2apex-agent-card-certification-directory	A2Apex]]，AgentMesh 的 `AgentCard` 不是公共 trust directory，而是可执行调度约束：agent 是否有 capability、能处理哪个 data level、成本是多少。

对 Agent-Benchmarks 来说，它提醒 benchmark 不应只记录模型名和 pass rate，还要记录 task envelope、runtime placement、authority decision、budget gate、receipt hash 和 evidence boundary。

对 Hermes / llm-wiki 的可执行启发

为 cron/job 引入轻量 task envelope。 每个自动任务至少记录 job id、目的、允许能力、可写路径、数据级别、是否允许发布/删除、预算/超时、需要哪些 receipt。
区分 task-level gate 与 action-level gate。 task-level gate 决定这类任务可进入哪个 runtime、拿哪些工具；action-level gate 决定某次 GitHub/文件/发布/API 调用是否 allow/review/block。
把 runtime placement 纳入入库字段。 对 sandbox/security 相关候选，记录它是否支持 rootless container、microVM、dedicated VM、Kubernetes SandboxClaim、workload identity、egress policy 与 post-effect verification。
报告 receipt 边界。 AgentMesh 在 report 中明确说 deterministic plan 不证明 Kubernetes sandbox 已创建或外部 action 已执行；Hermes 报告也应继续区分“已写文件/已运行命令/已验证公网链接/未能访问”。

失败模式 / 边界条件

README 自称是 deliberately small interoperability kernel，不是 MCP/A2A 完整合规认证；生产部署仍需要 authenticated transport、external policy store、workload identity、durable workflow engine、signed artifacts 与 recovery procedures。
receipt_sha256 证明 decision 内容稳定，不证明后续执行没有绕过 gateway，也不证明外部系统状态正确。
当前可读证据主要来自 README、示例、planner/render 代码和单元测试片段；GitHub API 在本轮 rate-limited，未完整读取仓库全部代码，也未本地运行测试，因此 confidence: medium。
AgentCard 如果只记录 capability 和成本而不记录 owner、auth、card hash、last_verified_at、trace destination 与 risk tier，会在开放 A2A 环境中不足以抵御 registry poisoning。

候选评分

维度	分数	理由
relevance	5/5	同时命中 MCP Gateway、A2A、harness-runtime、benchmark-evaluation、sandbox-security。
novelty	4/5	与已有 gateway/trust 页面重叠，但 task envelope + runtime placement + receipt bundle 组合有新增机制价值。
durability	4/5	pre-execution planning、SandboxClaim、OTel receipt 会长期影响 agent runtime 设计。
actionability	5/5	可直接迁移为 Hermes cron/job policy、tool profile、receipt boundary 和 benchmark 字段。
source-quality	3/5	GitHub README/代码/测试片段可读，但项目低星且未本地运行；部分文件 fetch 超时/API rate limit。
depth-potential	5/5	能深化 task-level control plane、sandbox placement、A2A/MCP registry 与 evaluation receipts 的关系。

写入记录

2026-09-06 09:00 CST：基于 AgentMesh Runtime Gateway README、Azure Terraform 示例、planner/render 代码和 planner tests 新建 source 页，提炼 task envelope、runtime placement、SandboxClaim、OpenTelemetry-shaped event 与 deterministic receipt 对 Hermes agent runtime 的启发。
2026-09-10 12:03 CST：将 MCP Gateway / Harness 主题关联补入正文，避免关联仅存在于发布时被剥离的 related 元数据；未改变项目验证范围。