Agentrc：用 Dockerfile 式规范打包与治理 AI Agent
开发者推出 Agentrc 规范，以类似 Dockerfile 的 Agentfile 声明 Agent 身份、能力和策…
AI Agent 的形态正变得碎片化：不同框架、不同模型、不同部署环境之间缺乏统一的「打包」与「治理」约定。近日在 Hacker News 上亮相的开源项目 Agentrc，试图把容器世界里 Dockerfile 的思路搬到 Agent 领域，用一个声明式文件描述 Agent 的全部属性，再编译成标准的 OCI 制品跨平台分发。
核心思路：把 Agent 当成容器来打包
Agentrc 的核心抽象是「Agentfile」，其写法刻意沿用了 FROM、COPY、CMD、HEALTHCHECK 等熟悉的 Dockerfile 关键字，并新增了四个面向 Agent 的原生关键字：
- IDENTITY：声明 Agent 名称、版本、作者与描述。
- CAPABILITY：声明能力范围，例如 text、tool-use 等。
- SOP：系统提示词（System of Prompt），定义 Agent 的目标与边界。
- POLICY：以类型化方式「请求」模型、工具超时、网络出口等资源。
一个最简示例展示了从基础镜像、身份、能力到本地工具挂载的完整流程，编译后会产出带有 ai.agentrc.* 命名空间标签的 OCI 制品，行为上与普通容器镜像一致，可以推送到任意 OCI 镜像仓库。
策略不是口号，而是可审计的契约
Agentrc 强调「Policy, not hope」。Agentfile 中的每一行 POLICY 都是一次显式请求，平台可以「授予、收窄或拒绝」，最终由 Cedar 策略引擎以「默认拒绝」的方式执行。
这意味着：
- 模型选用：
POLICY model.name claude-sonnet-4只是一种请求，运行时可被替换。 - 工具超时：
POLICY agent.tool_timeout 30s可被平台强制覆盖为更严格的阈值。 - 网络出口：
POLICY network dns:api.example.com:443受 Cedar 规则约束。
安全团队因此可以在不接触 Agent 源码的前提下，对其权限边界做形式化审查。
一份制品，三种运行环境
Agentrc 把「声明」与「执行」严格分离：Agentfile 只表达意图，标签才是契约。同一份 OCI 制品可通过 arc run --backend 翻译为不同后端的部署形态：
- 本地后端：直接以 dry-run 方式打印将执行的配置。
- AWS Bedrock：生成 CreateAgentRuntime 所需的 JSON。
- Kubernetes：生成对应的 deploy manifests。
项目作者明确把上述翻译器定位为「参考实现」，在目标平台原生支持 ai.agentrc.* 标签之前，作为概念验证使用，尚未达到生产级别。
安装与现状
CLI 工具 agentrc（别名 arc）提供 init、lint、build、run、push 等子命令，可通过一行脚本、Homebrew 或 Go 1.25+ 安装。项目以 Working Draft 0.1.0-draft.6 形式发布，目前包含四个关键字、/mnt 工具挂载约定、OCI 标签规范和 Cedar 执行机制，密钥管理被列为下一阶段议题。
整体来看，Agentrc 仍处于早期个人项目阶段，生态适配与平台原生支持均待建立，但其把「可治理」作为一等公民的设计思路，对正在快速膨胀的 Agent 工程化议题提供了一个值得关注的切入点。