AtlasClaw：企业级 AI Harness 工程

为什么需要企业级 AI Harness

个人 Agent 本身没问题。它轻、快、灵活，适合先让一个人的效率跑起来。但企业一旦推广，问题就变成：这些能力能不能被组织长期管理。

如果开发、测试、业务、经理和 CIO 都各自配置 Agent，再分别接入 OA、ITSM、SmartCMP、监控、Jira / GitHub 等系统，效率会提升，安全、合规、成本和审计也会一起分散。

• 配置各搞各的：连接器版本、提示词、模型参数、脚本和工具清单很快对不上。

• 凭证留在个人手里：Cookie、API Token 或个人授权分散在个人环境里，交接、变更和轮换都会变麻烦。

• 权限不好解释：Agent 到底能看哪些工具、又以谁的身份访问系统，管理者很难一眼看清。

• Context 和 Memory 不受控：哪些业务数据能进上下文，哪些能沉淀成长期记忆，必须有统一规则。

• 模型执行不好管：不同人选择不同模型和调用策略，Token 怎么花、哪些流程重复推理，企业很难算清楚。

• 审计和协作没人兜底：会话隔离、流程确认、结果回写和事后追溯，本来就应该由企业系统统一处理。

每个人都能把Agent接到系统上，但配置、凭证、权限、Context、Memory、审计和成本也会分散到个人侧

这就是AtlasClaw的切入点。它不是和个人 Agent 比谁更会聊天，而是把 Agent 放到企业级 AI Harness 里，让自然语言交互和企业级治理同时存在。

AtlasClaw 的定位：企业级 AI Harness Runtime

AtlasClaw 可以理解成企业内部的一层 AI Harness Runtime。用户可以从 Web、IM、Webhook 或现有系统入口进来；AtlasClaw 统一处理身份、会话、模型执行、Context、Memory 和工具调用；访问具体业务系统时，再交给对应的 Provider / Skill。

入口可以不同，任务可以不同，但背后用的是同一套 Harness。系统接入不用重复做，权限边界、Context 和 Memory 也可以由组织统一制定。

不同角色共享 AtlasClaw 这层 AI Harness，再通过 Provider / Skill 连接企业已有系统

AI Harness 要管什么	企业侧关心什么
安全与合规	身份、角色、凭证、敏感数据、审计和留痕要有统一边界，不能散在个人工具里。
模型执行	模型选择、调用策略、工具权限、写操作确认和 Token 成本要能被组织看见。
Context 管理	用户身份、页面状态、业务对象和系统数据进入上下文前，要有范围和来源控制。
Memory 管理	会话、短期记忆、长期记忆需要按用户隔离；哪些能沉淀、哪些必须排除，要有策略。
Provider / Skill	系统认证、业务对象和操作规则放在 Provider 中，减少重复脚本和不可控接口。

“轻核心 + 富 Provider”听起来像技术术语，本质并不复杂。AtlasClaw 核心负责通用 Harness 能力；每个业务系统自己的登录方式、业务对象、脚本和操作规则，则放在 Provider 里处理。这样既保持核心轻量，也方便持续扩展。

很多系统加 AI 时，第一反应是做一个外部聊天入口。演示时方便，但用户真正工作时要切换页面、复制上下文、重复确认身份，时间一长就不好用了。更好的方式，是把 Harness 放进原系统页面、菜单或工作流里。

AtlasClaw 支持 iframe、嵌入页面或路由子应用等方式。宿主系统提供身份和页面上下文，AtlasClaw 在调用 Provider 时继续沿用当前请求里的边界。

这和“页面上挂一个聊天框”不是一回事。Agent 要能拿到当前用户、页面和业务对象，执行时仍走原系统权限和审计，结果也能回到申请单、审批单、告警或资源页面。

AtlasClaw 可以作为现有系统里的 AI Harness 使用，沿用当前上下文，并把结果写回原流程

企业 App 调用 AtlasClaw：流程里的智能员工

嵌入式模式解决的是“人在系统里怎么用 Agent”。企业 App 还有另一类需求：流程走到某个节点时，由系统主动把任务交给 AtlasClaw。此时，AtlasClaw 更像一个有岗位边界的智能员工。

典型方式是 Webhook Robot Execution：企业 App 发送事件，指定 Skill、Provider 实例、robot profile 和业务对象 ID；AtlasClaw 校验权限后，再用受控机器人凭证执行。

机器人不是“想做什么就做什么”。它只能处理授权节点，只能调用白名单 Skill，写操作必须留下原因和结果。

以 骞云SmartCMP 的 preapproval-agent 为例，它会读取审批详情和预审批规则，判断通过、驳回或转人工。这不是替代审批制度，而是把固定、重复、可解释的初筛交给 Agent 先做一遍。

SmartCMP 集成示例：从云管助手到流程智能员工

SmartCMP 是骞云云自动化管理系统，也是 AtlasClaw 嵌入式实践中很典型的场景。云管平台天然包含资源目录、申请流程、审批机制、运维操作、告警、成本和合规数据。AtlasClaw 嵌入后，既可以做云管助手，也可以作为机器人同事参与流程节点。

比如开发人员说“帮我申请一台两周后释放的测试云主机”，AtlasClaw 会理解目标，查询服务目录、模板、镜像和资源池；参数不够就继续追问；用户确认后再提交申请并跟踪状态。进入审批节点后，也可以由 preapproval-agent 先做预审。

SmartCMP里做什么	用户或系统会怎么触发	Harness/Agent处理什么
资源申请	用户说：“帮我申请一台测试用云主机，给研发组用两周。”	整理目标和资源上下文，查目录、模板和资源池，确认后生成申请单。
审批预审	SmartCMP 在审批节点触发 preapproval-agent。	读取申请详情、目录预审策略和审批历史，给出通过、驳回或转人工，并写回原因。
资源查询	用户说：“看看我名下有哪些云主机，哪些长期空闲。”	按当前用户权限查询资源、资源池和业务组，返回可追溯视图。
运维操作	用户说：“把这台测试机开机，先确认它允许执行这个操作。”	先检查可执行操作，确认后再调用 SmartCMP 受控接口。
告警分析	监控或用户把告警交给 Agent 分析。	读取告警和资源上下文，给出排查方向；状态操作仍需用户或机器人权限确认。
成本优化	系统定期触发，或用户询问本月节省建议。	读取优化建议，分析影响范围和节省空间，后续跟踪整改状态。
合规分析	巡检流程或用户要求检查一批云主机。	结合资源详情分析生命周期、补丁、安全与配置状态。

SmartCMP 嵌入 AtlasClaw 后，用户目标会经过上下文整理、目录匹配、审批确认、受控执行和审计回写

这里不能忽略一个前提：SmartCMP 仍然是云资源和流程的事实来源。AtlasClaw 不绕过云管平台，也不替用户偷偷执行高风险动作；最终都要落回 SmartCMP 可处理、可审批、可审计的操作。

企业最终要的是可持续运行的 Harness

很多企业做 Agent 试点，第一步会先证明“AI 能接 API”。但进入生产环境以后，真正重要的是共用、流程调用、写操作确认、Context / Memory 边界，以及机器人身份和人工身份的审计。

AtlasClaw 关注的正是这些落地问题。它把 Agent 从个人工具变成企业可运营的一层 Harness：统一部署、共享 Provider、嵌入业务系统，并作为受控智能员工参与流程。

换句话说，企业要的不是一堆会回答问题的 Agent，而是一套能管理模型执行、上下文、Memory、权限、审计和业务系统边界的 AI Harness。

AtlasClaw 是开源项目。核心框架负责通用 Harness 运行时，Providers 仓库负责系统接入。企业可以先从已有 Provider 试用，也可以按自己的系统扩展新的 Provider。

选择开源，是因为企业系统本来就各不相同。AtlasClaw 希望把通用 Harness 做扎实，把差异化接入交给 Provider 生态逐步补齐。

AtlasClaw 核心框架	AtlasClaw Providers
https://github.com/CloudChef/atlasclaw	https://github.com/CloudChef/atlasclaw-providers

如果你的团队已经在试用个人 Agent，并准备把它带进真实业务系统，可以把 AtlasClaw 看成下一步：不是给每个人再发一个新工具，而是补上一层企业级 AI Harness，让 Agent 能被共享、被管住，也能作为智能机器人参与业务流程。