OrgKernel 智能体信任内核
用密码身份、限权令牌和哈希审计链约束智能体执行。
令牌具有工具白名单、不可变参数、数值边界和过期时间，且身份可暂停、撤销，最小权限设计证据充分。README还说明私钥仅返回一次且不持久化，并展示审计数据流、拒绝记录和令牌提前失效。不过，没有完整的用户确认或审批协议；示例可能把工具参数和结果写入审计日志，却没有脱敏、访问控制、保留期或加密说明。依赖仅设置最低版本，没有锁文件、上限、漏洞扫描或依赖缓解流程，SECURITY.md还把第三方依赖漏洞排除在范围外。来源归属指向Metaprise并提供联系渠道，但发布者身份未经策展注册表验证。
Python版本、包元数据、核心模块和示例总体一致，常见依赖及数据库可选项也有明确声明，错误路径展示了PermissionError和完整性检查消息。主要扣分来自内部矛盾：README声称治理“不可绕过”且“没有绕过代码路径”，但集成示例要求应用开发者自行包装每个工具调用，未展示强制拦截机制；README把SSO/SCIM列为未来能力，而SECURITY.md又把相应集成列入安全报告范围。没有给出更全面的失败消息、恢复分类或依赖不可用处理。
面向开发者、系统管理员及金融、医疗、保险、法律等企业场景的受众和用例描述充分，并提供服务层、FastAPI及多种代理框架的集成模式。边界方面明确区分现有三个模块与未来能力，但“不可绕过”的表述超过所示包装器证据，SSO/SCIM状态也不一致。触发点被描述为每次工具调用前检查、之后审计，但正确覆盖仍依赖集成方。Python 3.10+和三种数据库适配较清楚，不过缺少部署、密钥管理、迁移和生产环境配置细节。
README组织良好，涵盖架构、安全模型、快速开始、API、模式和框架集成；命名约定与27个端点也较具体。安装仅覆盖源码可编辑安装，没有发布包、迁移、环境变量、生产部署或升级步骤。许可证文件和元数据一致，Apache-2.0证据完整。pyproject声明1.0.0和Beta，并链接CHANGELOG，但提供的材料不含CHANGELOG内容或发布策略。维护者、作者、安全邮箱和响应时间明确，但未知发布者身份及仅支持main使长期维护和稳定更新路径的证据有限。缺少专门FAQ，已知限制披露也很薄。
服务层、REST端点、curl和通用工具包装器使输出具有直接集成价值，身份、细粒度授权和可验证审计的组合相较普通代理编排具有明显增量价值。扣分在于示例并非完整生产方案，工具调用的实际强制覆盖、日志访问控制及运维流程仍由采用者实现。项目声称可自托管、无API密钥和无回传，降低供应商成本，但引入数据库、CA密钥保管、包装所有工具及审计存储的成本未被量化或深入讨论。
若干主张可追溯到具体接口、字段、端点、算法和配置，例如Ed25519、SHA-256链、令牌边界及依赖清单。README、pyproject、LICENSE和SECURITY.md对名称、许可和核心定位有一定交叉印证，但没有提供核心实现文件、测试、变更日志或独立材料来佐证强安全主张。“不可绕过”“每个生产部署都使用”“合规级证据”和攻击防护等表述没有与推断或营销主张清晰分开，且部分与所示集成模式或路线图状态冲突。
- “不可绕过”主张未由所示架构证明；通用集成依赖开发者在每个工具边界正确安装包装器，遗漏调用可能绕过范围检查和审计。
- 审计示例记录工具参数及结果，但材料没有说明敏感字段脱敏、日志访问控制、静态加密、保留期或删除治理。
- 私钥由服务端生成并返回一次，生产部署需要另行验证CA私钥保护、传输安全、密钥轮换、备份和灾难恢复。
- 依赖使用开放式最低版本且未提供锁定或漏洞管理证据；在安全关键部署前应独立审查依赖解析结果。
- SSO/SCIM在README中是未来能力，却出现在SECURITY.md范围内；采用前应确认当前版本实际包含哪些组件。
- 本结论仅基于所给静态文件，未执行代码、测试密码学实现或验证运行时强制性。
这个 Agent 能做什么，适合哪些场景？
OrgKernel 是一个可自行部署的 Apache 2.0 Python 信任层，用于在智能体调用工具时验证身份、限制权限并记录可校验的执行历史。其三个现有核心模块是 AgentIdentity、ExecutionToken 和 AuditChain：分别提供由组织 CA 签发的 Ed25519 身份、实例与任务范围的执行令牌，以及 SHA-256 哈希链审计记录。项目既提供异步 Python 服务类，也提供可挂载到 FastAPI 的 27 个 REST 端点，并通过 SQLAlchemy Async 将数据保存到 PostgreSQL、MySQL/MariaDB 或 SQLite。它位于工具调用边界：执行前调用 ExecutionTokenService.check_scope()，执行或拦截后通过 AuditChainService.append() 写入记录，最终可用 verify_integrity() 检查删除、修改或重排。它不负责构建或编排智能体，而是可包装 LangGraph、CrewAI、AutoGen 或自定义循环中的工具层。当前可用范围应与路线图区分：身份、执行令牌和审计链被标为可用，而任务生命周期、工具网关、策略引擎、权限图、数据分类、SSO/SAML 和 SCIM 仍属后续计划。
典型流程从 AgentIdentityService.submit_csr() 或 issue_from_csr() 开始：系统处理智能体名称、组织、组织单元、公钥和用途，签发由组织 CA 签名的证书，并仅在签发时返回一次私钥 PEM；持久化身份记录不保存私钥。验证方可用 request_challenge() 生成有效期五分钟的一次性 nonce，再用 verify_challenge() 检查 Ed25519 签名、证书状态和有效期。ExecutionTokenService.mint() 为指定 agent_id 和 mission_id 创建由组织 CA 签名的限时令牌，其中包含工具白名单、必须完全匹配的 immutable_params 和数值范围 bounded_params；check_scope() 会检查令牌、调用者身份、工具名称和参数约束，并返回允许或阻止结果。AuditChainService.initialize() 创建包含初始 IDENTITY 记录的审计链，append() 写入执行或合规事件，close() 关闭链，verify_integrity() 重算内容哈希并检查序号及 prev_hash 连续性。服务可以直接嵌入异步 Python 应用，也可挂载 orgkernel.pyapi.router，在 /orgkernel 下暴露身份、令牌和审计 API。
- 金融、医疗、保险或法律系统团队需要为每次智能体工具调用留下可重放、可独立验证的审计证据。
- 平台工程团队已经使用 LangGraph、CrewAI、AutoGen 或自定义智能体循环，希望在工具边界加入统一的身份验证和执行范围检查。
- 安全团队需要给单次任务签发数小时有效、仅允许特定工具且限制金额等数值参数的最小权限令牌。
- 合规负责人需要查询某个智能体或任务的行为，并检测审计条目是否被删除、修改或重新排序。
- 企业希望在自己的基础设施中运行信任层，选择 PostgreSQL、MySQL/MariaDB 或 SQLite，而不依赖托管 API 密钥或回传服务。
这个 Agent 有哪些优点和局限？
- DualToken 模型要求组织身份凭证和实例范围执行令牌同时有效，并在范围检查中核对 token.agent_id 与调用者身份。
- 执行令牌支持工具白名单、完全匹配的不可变参数、数值上下界和过期时间，比长期共享 API 密钥更细粒度。
- 审计记录通过 SHA-256 内容哈希、prev_hash 和连续序号检测删除、修改及重排，并提供完整性验证 API。
- 同一套服务可作为异步 Python 库或 27 个 FastAPI REST 端点使用，并支持 PostgreSQL、MySQL/MariaDB 和 SQLite。
- 工具边界包装方式不依赖特定编排框架，README 明确给出 LangGraph、CrewAI、AutoGen 和自定义循环的接入模式。
- 接入方必须改造每个工具调用路径，在执行前检查范围、执行后同步写审计；遗漏包装的调用路径不会自动获得治理。
- 签发流程示例会在服务端生成并仅返回一次智能体私钥，部署方必须自行建立安全接收、保存和轮换私钥的流程。
- 生产部署需要运营 Python 异步服务、组织 CA 和数据库；README 没有提供容器、托管服务或完整生产拓扑。
- 任务生命周期、工具网关、策略引擎、权限图和数据分类仍列在路线图中，不能按现有能力采购。
- SSO/SAML 2.0 与 SCIM 2.0 仍是后续计划；尽管仓库描述提到企业联合能力，README 的功能状态并未将其列为当前可用。
如何安装或部署这个 Agent？
需要 Python 3.10+、Git 和可选数据库驱动。执行：
git clone https://github.com/MetapriseAI/OrgKernel.git
cd OrgKernel
pip install -e ".[postgres]"可将 postgres 替换为 mysql 或 sqlite；README 推荐 PostgreSQL，SQLite 面向本地开发。安装过程需要网络获取仓库和 Python 依赖。运行服务前，把 async_engine.url 设置为对应的 SQLAlchemy 异步数据库 URL并调用 await init_db()。项目运行在自有基础设施，不需要 OrgKernel API 密钥。
如何使用这个 Agent？
直接使用服务层时，从 orgkernel.services 导入 AgentIdentityService、ExecutionTokenService 和 AuditChainService，并向服务传入 AsyncSession。先用 AgentIdentityCSR 调用 identity_svc.issue_from_csr(csr) 签发身份；再用 ExecutionTokenCreate 调用 token_svc.mint(...)，设置 agent_id、mission_id、execution_scope、参数约束和未来的 expires_at；每次工具调用前，用 ScopeCheckRequest 调用 token_svc.check_scope(...)。若检查未通过，应阻止工具执行并通过 audit_svc.append(...) 记录 EXECUTION_tool_blocked；若通过，则执行工具并记录 EXECUTION_tool_call。任务开始时调用 audit_svc.initialize(...)，完成后可调用 audit_svc.verify_integrity(...)。若需要 HTTP 接口，创建 FastAPI 应用、在启动阶段配置 async_engine.url 并调用 init_db()，然后执行 app.include_router(router, prefix="/orgkernel", get_db=get_db)；这会挂载 README 所列的 27 个端点。
这个 Agent 与同类方案有什么区别？
与单独使用 LangGraph、CrewAI 或 AutoGen 相比，OrgKernel 不替代编排，而是在工具执行路径补充可验证身份、限权授权和防篡改审计。与每个智能体配置 API 密钥相比，其 ExecutionToken 有任务范围、参数边界、签名和有效期。与普通应用日志相比，AuditChain 使用 SHA-256 哈希链接并提供完整性检查，但接入方仍需保证所有执行路径都经过范围检查和同步审计写入。