Orloj：把 Agent 当基础设施管理

Agent 原型往往只有模型客户端、循环和几个工具。上线之后却会冒出身份、权限、Secret、Schedule、Retry、Worker Ownership、预算、审计，以及一个最朴素的问题：“现在到底在跑什么？”Orloj 的判断是，这些东西应该成为可版本化资源，而不是继续塞进应用胶水代码。

先说结论

• Orloj 是 Agent 系统的运行与治理层，不是模型 SDK，也不是 Prompt 框架。
• 它最有价值的部分是声明式资源、Fail-closed 工具策略、租约式任务认领、幂等、Dead Letter 与 Trace。
• 它更适合长期运行、需要治理的多 Agent 工作负载，而不是还在探索单个聊天 Agent 的团队。
• 项目尚未到 1.0，API 与 Resource Schema 仍可能改变。
• YAML 能集中表达意图，却不能替代端到端的策略、工具和故障测试。

Orloj 实际运行哪些组件

官方文档把运行时拆成三部分：orlojd 提供 REST API、资源存储、Scheduler 和后台服务；一个或多个 orlojworker 认领并执行任务、路由模型请求、运行工具；orlojctl 负责 Apply Manifest、提交任务和查看日志、图、Trace 与 Event。

开发环境可使用内存存储与 Embedded Worker，生产形态则可拆分 Server 与 Worker。来源：Orloj Docs。

本地起步时，一个进程就能工作；更接近生产的部署可以用 PostgreSQL 保存状态，用 NATS JetStream 驱动消息式 Worker。Manifest 不必为了从笔记本迁移到集群而改写成另一套应用。

用资源替代框架对象

关注点	代表资源
执行	Agent、AgentSystem、Task、Worker
模型与工具	ModelEndpoint、Tool、McpServer
状态与凭据	Memory、Secret、SealedSecret
治理	AgentPolicy、AgentRole、ToolPermission、ToolApproval
触发	TaskSchedule、TaskWebhook

资源拥有带版本的 Metadata、期望 Spec 和可观测 Status。平台团队因此能在 Pull Request 中直接看见：某个 Research Agent 新增了什么 Web Tool，Token 上限为何提高，Workflow 又多了哪条 Review Edge，而不是去 Python 控制流里寻找隐藏变化。

CLI、Console、REST API 与 SDK 也能围绕同一种资源说话。Python SDK 可以用 Graph-as-code 写定义、通过 SSE Watch Task，但最终状态仍在 Orloj Control Plane 中，而不是困在单个 Python 进程里。

生产任务首先是分布式系统问题

很多框架都能跑 DAG。Orloj 更值得注意的是租约式 Claim、带 Jitter 的上限重试、幂等追踪与 Dead-letter Transition。

假设 Worker 认领任务、调用外部 API，然后在写回完成状态前崩溃。Lease 过期后，另一台 Worker 会接手。如果它无脑重复所有步骤，外部动作可能执行两次。没有副作用幂等边界的 Retry，不叫可靠性。

Orloj 可以追踪 Task Identity 与 Execution State，但最后一公里仍归 Tool 作者负责。创建工单、发邮件、Push Commit 的工具应接收 Idempotency Key，或在写入前检查既有状态。运行时无法猜测任意 Shell 命令是否能安全重放。

Orloj 把 Agent Team 明确视作需要租约、Retry、幂等与 Dead Letter 的分布式系统。来源：OrlojHQ/orloj。

Lease 时间也要调。太短，慢模型调用会被误判为 Worker 死亡；太长，真故障恢复又拖得太久。Trace 必须区分首次 Attempt 和 Replay，并记录每次副作用对应的 Lease Owner。

治理必须在执行路径上生效

Orloj 可声明 Agent 能用哪些工具和模型，以及 Token、Cost、Step、Timeout 如何限制。关键不在于 Manifest 写了规则，而在于 Fail-closed：未授权调用由运行时拒绝，不靠 System Prompt 劝模型自觉。

这才是正确层级。“不要写文件”这句话会与模型之后读到的所有指令竞争；根本不暴露 file_write，或在执行前拒绝调用，才能把决定权从模型手里拿走。

合理的角色拆分可以是：Researcher 只有白名单网络读取；Analyst 只接触上游产物；Developer 在沙箱里拿限定仓库工具；Reviewer 只读 Diff 与 Test Output；Publisher 只有一个必须人工批准的写入 API。

策略还必须同时覆盖同步和消息式执行路径。公开 Go Package 文档特意写明两条路径都要执行 Policy Enforcement——这种关键不变量应写进集成测试，而不是只相信架构说明。

工具隔离不是一个开关

Orloj 支持 Container、WASM 与 Sandbox 工具执行。MCP Server 可以在 Read-only Root FS、Drop Linux Capabilities、限制 CPU 与内存的容器里运行；需要文件凭据的 Server，也能用 Mount File 而非环境变量接收 Secret。

这些是好用的 Primitive，不是安全保证。允许任意 Egress 的容器仍能外泄输入；只读 Root FS 也不会阻止它写挂载的 Workspace。部署仍需网络策略、窄挂载、非 Root 用户、镜像 Pin 和 Secret Scope。

SealedSecret 让加密 Manifest 可以进入 Git，再由 Server Reconcile 成运行时 Secret。这也带来密钥管理责任：备份与轮换 Sealing Key、限制 Unseal 路径，并预先定义密钥丢失后的恢复方式。

Graph 有用，Loop 必须有硬边界

Orloj 支持 Pipeline、Hierarchy、Fan-out/Fan-in 与 Swarm Loop。Pipeline 最容易推理；真正独立的分支用 Fan-out 能降低墙钟时间；Loop 最危险，因为模型常常参与判断“还要不要再来一轮”。

每个 Loop 都应该有确定性的最大迭代次数，同时限制 Step、Token、Cost 与 Wall Clock。退出判断要落成数据。代码评审循环最好以“测试通过且无 Blocking Finding”为结束条件，而不是一句自由文本 “looks good”。

Join 同样要说清：一个分支失败时，是阻塞整体、生成部分结果，还是进入 Dead Letter。静默 Partial Success 尤其危险，因为下游 Agent 会误以为证据集完整。

Changelog 是必读文档

Orloj 明确处于 Pre-1.0。Changelog 展示了很快的扩展速度：Container MCP、Ephemeral Session、Sealed Secret、SDK、Evaluation、Console，以及 Provider 专属 Tool-call History 修复。

新资源不断加入，模型适配的执行细节也仍在修复。来源：Orloj Changelog。

Server、Worker、CLI 和 SDK 应一起锁版本。升级前验证 Manifest，再在非生产 Namespace 重放代表性任务。Streaming、Tool Error、拒绝审批与被中断的多步调用，都应成为 Provider Adapter 的回归用例。

Orloj 与 Agent Framework 的分界

LangGraph、Microsoft Agent Framework、CrewAI 与 OMA 主要帮助应用开发者表达 Agent 行为和协作。Orloj 的目标更接近它们周围的运行平面。功能有重叠——Orloj 同样有 Graph、Tool 与 Model Routing——但差异在 Fleet Lifecycle 与 Governance。

Python 团队还在每天改 Prompt 和 Graph 时，In-process Framework 更快。多个团队开始需要统一身份、Policy、Schedule、Cost Attribution 与 Worker Operations 时，独立 Control Plane 才会逐渐值回复杂度。

这也解释了它与上一篇 Open Multi-Agent 动态 DAG 的差别：OMA 嵌进 TypeScript 应用，重点是可检查的运行时任务图；Orloj 则把整个 Agent 系统变成声明式平台资源。

一条负责的采用路线

先选一个低风险、重复执行的 Workflow，用 Embedded Worker 跑。为 Agent、Tool、Limit 与 Policy 写 Manifest，高影响工具暂不开放，并准备一组 Golden Input 与结构化预期结果。

下一步拆出 Worker，切到持久存储。在模型调用和工具执行中途主动 Kill Worker，验证 Lease Recovery、Idempotency、Trace 连续性与 Dead-letter 行为。只读流程可靠后，再增加一个 Approval-gated 写工具。

最后用 Golden Set 重放升级，对比 Cost、Step、Denied Call、Output 与 Latency。Console 适合人排查，但这些验证也必须能自动执行。

常见问题

Orloj 是另一套 Kubernetes 吗？

不是。它借鉴声明式资源和 Control Plane 思路，但拥有面向 Agent 的 Server、Worker、Scheduler 与 Policy Runtime。

Orloj 会帮我自动写 Agent 吗？

不会。Agent Instructions、Tool、Model、Graph 与 Policy 仍由团队定义；Orloj 负责运行和治理。

API 已经适合长期稳定生产吗？

项目明确表示 1.0 前 Schema 仍可能变化。可以做生产评估，但必须锁版本并建立升级回归。

有 Retry 就能保证工具只执行一次吗？

不能。任意外部副作用无法由通用 Runtime 保证 Exactly-once。Mutating Tool 必须支持 Idempotency 与 Replay。

什么时候 Orloj 过重？

只有一个短生命周期 Agent、治理要求很少、没有持续运维负担时，In-process Framework 通常更简单。

最后的判断

Orloj 最有价值的洞察是：Prompt 与 Graph 只占生产 Agent 系统的一小部分。Ownership、Permission、Retry、Secret、Cost 与 Audit Evidence 同样需要一个运行上的家。

声明式 YAML 让这个家可以评审，但不会自动保证正确。只有团队像测试模型质量一样认真测试策略执行和故障恢复，这套平台才真正值得信任。