Contenox：为代理式 AI 工作流打造的本地运行时

Contenox 是一个 Apache 2 许可的本地运行时，用于将可重复的知识/工具工作流转换为版本化链。它将系统提示词、模型路由、工具白名单、重试、暂停、分支条件和人工审批门等关键决策显性化。

• 原作者/维护者：contenox
• 来源平台：github
• 原始标题：runtime
• 原始链接：https://github.com/contenox/runtime
• 来源发布时间/更新时间：2026-06-10T16:45:03Z

原作者与来源

• 原作者/维护者：contenox
• 来源平台：github
• 原始标题：runtime
• 原始链接：https://github.com/contenox/runtime
• 来源发布时间/更新时间：2026-06-10T16:45:03Z 原作者与来源\n\n- 原作者/维护者： contenox\n- 来源平台： GitHub\n- 原始标题： runtime\n- 原始链接： https://github.com/contenox/runtime\n- 发布时间： 2026年6月10日\n\n---\n\n项目背景：代理式 AI 工作流的痛点\n\n随着大型语言模型（LLM）能力的飞速提升，越来越多的开发者开始构建"代理式"应用——让 AI 不仅能回答问题，还能调用工具、执行多步任务。然而，这种新模式带来了一系列新的挑战：\n\n- 不可审计：系统提示词、工具权限、模型选择往往散落在代码各处，难以审查和版本控制。\n\n- 不可复现：同样的输入可能因模型随机性或环境差异产生不同输出。\n\n- 难以协作：团队成员难以理解某个工作流的具体行为和边界。\n\n- 缺乏治理：没有明确的审批门和策略控制，代理可能执行危险操作。\n\nContenox 正是为解决这些问题而生。它的核心理念是：将可重复的工作流打包成版本化的链（chain），让每个关键决策都显性化、可审查、可提交到版本控制。\n\n---\n\n核心概念：什么是链（Chain）？\n\n在 Contenox 中，链是工作流行为的声明式描述。每个决策都是一个 JSON 键：\n\njson\n{\n \"id\": \"review\",\n \"tasks\": [\n {\n \"id\": \"review\",\n \"handler\": \"chat_completion\",\n \"system_instruction\": \"You are a code reviewer...\",\n \"execute_config\": {\n \"model\": \"{{var:model}}\",\n \"provider\": \"{{var:provider}}\",\n \"tools\": [\"local_shell\", \"local_fs\"],\n \"tools_policies\": {\n \"local_shell\": { \"_allowed_commands\": \"go,make,npm,cargo,grep,cat\" }\n }\n },\n \"transition\": {\n \"branches\": [\n { \"operator\": \"equals\", \"when\": \"tool_call\", \"goto\": \"run_tools\" },\n { \"operator\": \"default\", \"goto\": \"end\" }\n ]\n }\n }\n ]\n}\n\n\n在这个例子中，你可以清楚地看到：\n\n- 系统提示词：代理的角色和行为准则\n- 模型配置：使用哪个模型、哪个提供商\n- 工具策略：允许使用哪些工具，命令白名单是什么\n- 分支逻辑：根据什么条件跳转到哪个步骤\n\n这种显性化的设计让工作流变得可审计、可版本控制、可协作审查。\n\n---\n\n主要特性\n\n1. 本地优先架构\n\nContenox 采用本地优先的设计理念：\n\n- 无需 API 密钥：contenox init 会自动注册本地 llama.cpp 后端，指向 ~/.contenox/models/\n- 离线可用：所有状态存储在本地 SQLite 中，会话在调用之间持久化\n- 数据主权：敏感数据不会离开你的机器\n\n2. 多后端支持\n\n虽然本地模型是默认选项，Contenox 也支持各种云端和本地模型提供商：\n\n- 本地服务器：Ollama、vLLM\n- 云提供商：OpenAI、Anthropic、Mistral、Gemini、AWS Bedrock、Google Vertex\n- 进程内：llama.cpp\n\n你可以根据工作流的敏感性和性能需求灵活选择。\n\n3. 丰富的工具集成\n\n任何可以通过 MCP、OpenAPI 规范或 shell 命令访问的服务都可以成为链中的工具：\n\nbash\nMCP 兼容服务器（Notion、Linear、Playwright、GitHub、Postgres 等）\ncontenox mcp add notion https://mcp.notion.com/mcp --auth-type oauth\n\n任何带有 OpenAPI 规范的 HTTP API\ncontenox tools add erp_billing --url https://erp.internal.example.com --spec ./billing-subset.yaml\n\nShell 命令\ncontenox --shell \"check Proxmox and flag anything red\"\n\n\n4. 编辑器集成\n\nContenox 支持 ACP（Agent Client Protocol），可以在编辑器中直接运行本地链：\n\n- Zed：通过 ~/.config/zed/settings.json 配置\n- JetBrains（GoLand、IntelliJ IDEA 等）：通过 ~/.jetbrains/acp.json 配置\n- AionUi：免费的本地开源桌面聊天 UI\n\n工具调用以卡片形式渲染，HITL（Human-in-the-Loop）提示通过编辑器的权限 UI 路由，会话历史在项目重新打开时恢复。\n\n---\n\n典型应用场景\n\nContenox 在以下场景中表现最佳：工作流具体且可重复，输入已知，工具已知，输出形状已知，且有明确的审查门。\n\n场景一：发布证据包\n\n- 输入：Git 日志、PR、工单、CI 输出\n- 输出：变更日志、风险说明、部署检查清单、审查者资料包\n- 门控：发布前人工审批\n\n场景二：API 到工作流包装器\n\n- 输入：内部 OpenAPI 规范\n- 输出：精选的工具子集、隐藏的租户/环境参数、认证处理、HITL 策略\n- 门控：变更调用的审批\n\n场景三：仓库维护链\n\n- 输入：工单或迁移请求\n- 输出：补丁、测试运行、PR 描述\n- 门控：shell/文件系统审批和人工合并\n\n---\n\n快速上手\n\nbash\n安装\ncurl -fsSL https://contenox.com/install.sh | sh\n\n初始化工作空间\ncontenox init\n\n拉取模型（第一个拉取的模型自动成为默认模型）\ncontenox model pull granite-3.2-2b\n\n使用\ncontenox \"say hello world in python\"\ncontenox chat -e 打开 $EDITOR 编写提示词\n\n启动本地 UI\ncontenox serve\n\n\n---\n\n技术架构\n\nContenox 采用 Go 语言编写，要求 Go 1.25+。项目结构清晰，包含多个核心库：\n\n- libacp：ACP 协议实现\n- libauth：认证处理\n- libbus：消息总线\n- libcipher：加密功能\n- libdbexec：数据库执行\n- libkvstore：键值存储\n- libroutine：协程管理\n- libtracker：追踪功能\n\n这种模块化设计使得 Contenox 既适合作为命令行工具使用，也可以嵌入到其他应用中。\n\n---\n\n实际意义与行业影响\n\nContenox 代表了 AI 代理工作流管理的一种新范式。与完全委托给 AI 的"黑盒"方案不同，Contenox 强调显式控制和可审计性：\n\n1. 企业合规：对于需要严格审计和合规的行业（金融、医疗、政府），Contenox 的显性化设计让 AI 工作流也能满足监管要求。\n\n2. 团队协作：链文件可以像代码一样审查、讨论和版本控制，让团队成员对工作流有共同的理解。\n\n3. 安全治理：通过工具白名单、命令限制和人工审批门，组织可以在享受 AI 自动化的同时保持风险控制。\n\n4. 渐进式采用：团队可以从简单的工作流开始，逐步增加复杂性和自动化程度，而不必一次性接受完全不可解释的 AI 决策。\n\nContenox 的出现标志着 AI 代理技术正在从"实验玩具"向"生产工具"转变。它提供了一个务实的中间地带：既享受 AI 的能力，又保持人类的控制和理解。