Agent OS 内核式治理完全指南从 FAQ 看懂确定性 AI Agent 治理架构的设计与落地【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkitAgent OS 是 Agent Governance Toolkit 中一个以内核kernel为设计隐喻的 AI Agent 治理运行时它把操作系统里策略、信号、受控执行的概念搬到自主 Agent 上在动作真正执行之前做确定性的拦截与校验而不是把安全寄托在模型听懂提示词上。本文以 Agent OS 官方 FAQ 为主线结合仓库内源码、策略 Schema 与内核实现细节系统解答它是什么、与框架和安全工具的关系、如何无侵入接入、如何编写自定义策略、何时可以上生产等核心问题帮助你判断 Agent OS 是否适合自己的治理场景并掌握从安装到自定义策略的完整实战路径。Agent OS 是什么一个治理内核而不是Agent 框架FAQ 给出的定义非常关键Agent OS 是用于治理自主 AI Agent 的内核式架构kernel-style architecture。它把操作系统中的概念——策略policies、信号signals、受控执行controlled execution——应用到 Agent 治理上在动作执行之前进行确定性的拦截与校验。它的核心定位是治理governance而不是 Agent 的创建agent creation。也就是说Agent OS 不帮你写 Agent 的业务逻辑它提供的是包裹在 Agent 外面的治理基础设施。在 agent-os/README.md 中这一理念被概括为Prompt-based safetyasks the LLM to follow rules. The LLM decides whether to comply.Kernel-based safetyintercepts actions before execution. The policy engine decides, not the LLM.基于提示词的安全是请求模型遵守规则是否遵守由模型决定基于内核的安全则是在执行前拦截动作由策略引擎做决定而不是模型。这与操作系统的工作原理同构应用程序请求资源内核根据权限决定授予还是拒绝。Agent OS 正是把这个机制复刻到 Agent 动作层并借用 POSIX 概念做了完整映射见 kernel-internals.md概念POSIXAgent OS进程控制SIGKILL、SIGSTOPAgentSignal.SIGKILL、AgentSignal.SIGSTOP文件系统/proc、/tmpVFS含/mem/working、/mem/episodic进程间通信管道\|Agent 间类型化 IPC 管道系统调用open()、read()kernel.execute()需要强调的是这是应用层Python 中间件的强制并非操作系统内核级的隔离Agent 与内核运行在同一进程内直接调用subprocess、open等标准库可以绕过内核。README 与 FAQ 都明确提示需要强隔离的生产场景应把 Agent OS 与容器或沙箱级隔离配合使用详见下文生产就绪度一节。与 LangChain、CrewAI 的关系构建者与治理者两者可以共存FAQ 回答了社区里最高频的疑问LangChain 和 CrewAI 是构建 Agent 的框架而 Agent OS 是包裹这些框架的治理基础设施。两者不是竞争关系而是互补关系。Agent → Syscall → Kernel Space → Policy Check → SIGKILL? │ │ │ ┌───────────────────┘ │ │ PASS │ ▼ └───── Execution (governed)来自 kernel-internals.md 的执行模型示意你完全可以在 LangChain、CrewAI、Semantic Kernel 或 OpenAI Assistants 之上叠加 Agent OS在执行期间强制安全策略与可审计性。仓库中的框架适配器清单见 integrations.md 与 README覆盖了 A2A、AgentShield、Anthropic、AutoGen、Amazon Bedrock、CrewAI、Gemini、Google ADK、Guardrails AI、LangChain、LangGraph、LlamaIndex、Microsoft Agent Framework、Mistral、OpenAI、OpenAI Agents SDK、Pydantic AI、Semantic Kernel、Smolagents 等 19 个适配器。以 LangChain 为例接入方式非常简洁README 的 Integration 示例from agent_os.integrations import LangChainKernel governed LangChainKernel().wrap(my_chain)这些适配器采用**懒拦截lazy interception**设计——在你真正调用.wrap()之前目标框架不必被安装进一步降低了接入成本。是否需要修改现有 Agent 代码不需要适配器负责包裹FAQ 明确回答不需要。Agent OS 通过适配器adapters以最小改动包裹现有 Agent 代码绝大多数集成工作就是用一个 KernelSpace 实例包裹你现有的 agent 或 executor然后定义策略。实际写代码时有两种路径路径一无状态内核StatelessKernel——零依赖核心README 的 30 秒快速开始from agent_os import StatelessKernel, AdapterExecutionState kernel StatelessKernel() ctx AdapterExecutionState(agent_iddemo-agent, policies[read_only]) result await kernel.execute( actiondatabase_query, params{query: SELECT * FROM users}, contextctx, ) # ✅ 安全查询执行 # ❌ DROP TABLE users → 被内核拦截路径二完整内核KernelSpace——需要pip install agent-os-kernel[full]附带信号、VFS 与保护环。快速开始文档 quickstart.md 给出了完整的工具注册 策略校验示例from agent_control_plane.kernel_space import KernelSpace, SyscallRequest, SyscallType from agent_control_plane.policy_engine import PolicyEngine from agent_control_plane.flight_recorder import FlightRecorder policy PolicyEngine() policy.add_constraint(my-agent, [echo, file_read]) # 白名单 recorder FlightRecorder(audit.db) kernel KernelSpace(policy_enginepolicy, flight_recorderrecorder) def echo_tool(message: str) - str: return fEcho: {message} kernel.register_tool(echo, echo_tool) ctx kernel.create_agent_context(my-agent) request SyscallRequest( syscallSyscallType.SYS_EXEC, args{tool: echo, args: {message: Hello, World!}}, ) result await kernel.syscall(request, ctx) # ALLOWEDecho 在白名单中从源码结构看src/agent_os/stateless.py无状态内核的设计目标正是 June 2026 MCP 兼容规范下的无会话状态、每次请求自带 ExecutionContext、状态外置到可插拔 StateBackend这使得任何内核实例都能处理任何请求便于水平扩展。README 中特别强调Wrong - bypasses governance直接调用工具会绕过治理Correct - goes through kernel通过内核 syscall 才受治理——这也是接入时需要遵循的核心约束。支持的 LLM 提供商模型无关治理的是动作而非输出FAQ 指出 Agent OS 是model-agnostic模型无关的OpenAIAnthropic本地模型Ollama、llama.cppLangChain、CrewAI、Semantic Kernel 支持的任意提供商关键设计原则是Agent OS 治理的是动作actions而不是模型输出model outputs。无论模型来自哪家Agent 最终要执行的工具调用、SQL、文件读写、API 请求都会以动作的形式经过内核因此治理逻辑天然与模型解耦。仓库中 integrations/ 目录下的openai_adapter.py、anthropic_adapter.py、bedrock_adapter.py、gemini_adapter.py、mistral_adapter.py、ollama相关适配及langchain_adapter.py等文件也从实现层面印证了多提供商适配、单一治理运行时的设计README 中的 Integration Comparison 表列出了各适配器的治理级别、异步支持与稳定性状态。如何编写自定义策略声明式配置 Python 助手 APIFAQ 说明策略通过基于规则的配置rule-based configurations或助手 API以声明式方式定义策略匹配已知的动作模式如文件写入、SQL 操作、API 调用并确定性地放行或阻止。自定义策略可以通过扩展策略引擎或编写新的规则定义来添加。在仓库中有两种正式的策略定义方式见 policy-schema.mdYAML 配置.agents/security.md——声明式、基于文件Python APIPolicyEngine——程序化、基于代码。Python API四类策略构件policy-schema.md 定义了PolicyEngine的四个核心能力① 白名单约束Allow-List最安全的默认from agent_control_plane.policy_engine import PolicyEngine engine PolicyEngine() engine.add_constraint(data-analyst, [file_read, database_query, api_call]) engine.add_constraint(admin, [file_read, file_write, database_query, database_write, code_execution])② ABAC 条件权限Conditional Permissionfrom agent_control_plane.policy_engine import Condition, ConditionalPermission refund_permission ConditionalPermission( tool_namerefund_user, conditions[ Condition(attribute_pathuser_status, operatoreq, valueverified), Condition(attribute_pathargs.amount, operatorlte, value1000), ], require_allTrue, # 两个条件都必须满足 ) engine.add_conditional_permission(support-agent, refund_permission) engine.set_agent_context(support-agent, {user_status: verified, department: customer-service})Condition支持完整的比较操作符集合eq、ne、gt、lt、gte、lte、in、not_in、contains、starts_with、not_starts_with、not_contains属性路径采用点号记法如args.amount、context.user_role。③ 资源配额Resource Quotafrom agent_control_plane.policy_engine import ResourceQuota quota ResourceQuota( max_requests_per_minute60, # 默认 60 max_requests_per_hour1000, # 默认 1000 max_execution_time_seconds30, # 默认 30 max_concurrent_executions5, # 默认 5 allowed_action_types[ActionType.FILE_READ, ActionType.API_CALL], ) engine.set_quota(my-agent, quota)④ 风险策略Risk Policyfrom agent_control_plane.policy_engine import RiskPolicy risk_policy RiskPolicy( max_risk_score0.8, # 高于此分数的动作被拒绝默认 0.8 require_approval_above0.5, # 高于此分数需要人工审批默认 0.5 deny_above0.9, # 高于此分数自动拒绝默认 0.9 high_risk_patterns[r\brm\s-rf\b, r\bdrop\stable\b], allowed_domains[api.internal.com, api.trusted.com], blocked_domains[*.malware.com], ) engine.set_risk_policy(production, risk_policy)内置保护Built-in Protections无论是否自定义策略PolicyEngine始终内置以下安全检查见 policy-schema.md路径穿越防护自动拦截含..的路径、/etc/、/sys/、/proc/、/dev/等系统目录及 Windows 系统路径危险代码模式code_execution中自动拦截rm -rf、磁盘格式化、DROP TABLE / DROP DATABASE、TRUNCATE TABLE、无 WHERE 的DELETE FROMSQL 注入防护自动剥离注释、检测多语句、阻止破坏性操作。自定义规则的判定接口check_violation是策略引擎对外的统一判定入口返回None表示放行返回字符串表示拦截原因violation engine.check_violation( agent_roledata-analyst, tool_namefile_write, # 不在白名单中 args{path: /data/output.csv}, ) if violation: print(fBlocked: {violation}) # Blocked: Role>def _check_policies(self, request: ExecutionRequest) - Optional[str]: for policy_name in request.context.policies: policy self.policies.get(policy_name) if not policy: continue # 检查动作黑名单 if request.action in policy.get(blocked_actions, []): return fAction {request.action} blocked by {policy_name} # 检查参数中的模式黑名单 params_str json.dumps(request.params).lower() for pattern in policy.get(blocked_patterns, []): if re.search(pattern, params_str, re.IGNORECASE): return fPattern {pattern} blocked by {policy_name} return None # 全部通过检查失败后会立即触发信号并返回失败结果error self._check_policies(request) if error: self.metrics.record_violation(agent_id..., action..., policy...) self.signals.send(request.context.agent_id, Signal.SIGKILL, reasonerror) return ExecutionResult(successFalse, errorerror, signalSIGKILL)请求模型配合与内核强制执行是两种完全不同的安全模型提示词安全把规则告诉LLM是否遵守取决于模型内核安全则把规则变成执行路径上的硬性拦截。README 中对比表也给出了同样的结论——NeMo Guardrails 和 LlamaGuard 这类工具负责模型调用前后的输入/输出过滤而 Agent OS 的差异化价值恰恰在执行期间的动作拦截。对策略执行失败的响应不只 SIGKILL 一种。Agent OS 的信号系统signal-handling.md定义了完整的 POSIX 风格信号族SIGSTOP暂停/进入影子模式、SIGCONT恢复、SIGINT优雅中断、SIGKILL立即终止不可屏蔽、SIGTERM请求优雅关闭、SIGUSR1诊断模式、SIGUSR2检查点、SIGPOLICY策略违规升级为 SIGKILL、SIGTRUST信任边界越界、SIGBUDGET资源预算超限、SIGLOOP检测到死循环、SIGDRIFT目标漂移。其中SIGKILL、SIGPOLICY、SIGTRUST不可屏蔽其余信号可以在临界区通过mask_signals()临时挂起排队。信号按 FIFO 顺序处理且全部自动写入 Flight Recorder 审计日志。与 Guardrails / LlamaGuard 等安全工具的关系纵深防御而非替代FAQ 明确指出Agent OS 不替代Guardrails、LlamaGuard 这类安全工具。原因在于作用时机的差异工具关注点作用时机NeMo Guardrails输入/输出过滤LLM 调用之前/之后LlamaGuard内容分类LLM 调用之前/之后Agent OS动作拦截执行期间Guardrails 类工具做的是输入/输出过滤input/output filteringAgent OS 则在执行期间拦截动作。两者可以组合使用形成纵深防御defense in depthGuardrails 管住模型说什么Agent OS 管住Agent 做什么。这一判断与仓库中 integrations/ 的guardrails_adapter.py、llamafirewall.py、agentshield_adapter.py等文件相互印证——Agent OS 甚至提供了与 Guardrails AI 协同的适配器说明共处一栈是被明确支持的使用方式。生产就绪度核心内核可上生产高级模块仍处实验期FAQ 对成熟度的表述非常克制核心内核组件策略引擎、信号处理、审计日志面向受控环境已达到生产可用而多 Agent 信任、验证、可观测性等高级模块仍处于实验演进阶段强隔离保障需配合容器或沙箱。README 的 Status Maturity 章节给出了精确的分级生产就绪Production-ReadyStatelessKernel零依赖策略执行、Policy Engine确定性规则执行、Flight Recorder基于 SQLite 的审计日志、CLIagent-os check/init/secure/validate、框架适配器、AGENTS.md 解析器以及 primitives、CMVK、EMK、AMB、IATP、ATR、Control Plane 等模块Control Plane 含 18 个测试文件。实验性ExperimentalObservabilityPrometheus 指标 OpenTelemetry 追踪暂无测试、MCP Kernel Server1173 行实现暂无测试、Control Plane 的 MCP/A2A 适配器占位实现。研究原型Research PrototypeNexus 信任交换网络无 pyproject、无测试、占位加密README 明示not secure。此外README 还诚实列出了已知架构限制这些是评估生产就绪度时必须考虑的现实约束限制影响缓解仅应用层强制直接调用subprocess、open可绕过内核生产环境配合容器隔离基于黑名单的策略规则未覆盖的新型攻击模式可能通过增加 AST 级解析、采用纵深防御Shadow Mode 单步多步 Agent 模拟与现实有偏差仅用于单轮校验审计非防篡改被攻陷的 Agent 可能修改 SQLite 审计日志关键审计写入外部接收端适配器与 SDK 耦合每个 SDK 需要独立适配器计划抽象统一接口对于生产可用的前提FAQ 的结论可以概括为一句话治理逻辑本身是成熟可靠的但治理边界只到应用层——想要真正可信的隔离必须叠加容器或沙箱。本地模型支持不依赖云 API治理逻辑运行在应用层FAQ 确认 Agent OS 完全支持本地模型它不依赖云 API可与本地推理栈Ollama、llama.cpp配合使用。原因在于治理逻辑运行在应用层独立于模型运行时——无论模型部署在哪里、由谁提供Agent 的动作都要经过内核这一层治理与推理彻底解耦。这对数据敏感、离线或合规要求严格的场景意义重大你可以在本地模型上获得与云端模型完全一致的策略执行与审计能力不需要把任何数据送到云端。如何参与贡献FAQ 列出的贡献方式包括改进文档、添加集成或示例、提出 RFC、修复 Bug 或改进测试。仓库对应地提供了完整的治理流程文档如 CONTRIBUTING.md、RFC_PROCESS.md、GOVERNANCE.mdAgent OS 的 docs 目录下还有专门的 roadmap.md 与 unified-vision.md 可供参考。快速上手从安装到第一个受治理 Agent结合 quickstart.md 与 README最快的上手路径如下# 基础安装Python 3.9 pip install agent-os-kernel # 或安装完整控制面模块KernelSpace、AgentSignal、AgentVFS 等 pip install agent-os-kernel[full]from agent_os import stateless_execute result await stateless_execute( actiondatabase_query, params{query: SELECT revenue FROM sales}, agent_idanalyst-001, policies[read_only], ) # ✅ SELECT 查询执行 # ❌ DROP TABLE users → 被内核拦截不是靠提示词而是靠内核也可以使用命令行工具agentos check/init/secure/audit/status/review/validate/install-hooks/serve/metrics详见 README CLI 章节将治理能力接入 pre-commit 钩子与 CI 流水线。如果想要进一步深挖建议按序阅读 policy-schema.md策略 Schema 全集、kernel-internals.mdsyscall 与信号内部实现和 signal-handling.md信号边界情况。一句话总结Agent OS 的价值主张可以浓缩为——Agent 框架负责构建安全工具负责过滤输入输出而 Agent OS 负责在执行中途拦截动作它以最小侵入、模型无关、确定性强制的方式把策略执行、审计与信号控制变成任何 Agent 应用都可叠加的治理层。【免费下载链接】agent-governance-toolkitAI Agent Governance Toolkit — Policy enforcement, zero-trust identity, execution sandboxing, and reliability engineering for autonomous AI agents. Covers 10/10 OWASP Agentic Top 10.项目地址: https://gitcode.com/GitHub_Trending/ag/agent-governance-toolkit创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考