Claude Code 和 artux 不是竞争关系，它们解决的是同一条链路上前后两段的问题。Claude Code 让一个工程师的产出翻倍——它跑在你的终端里，读你的代码库，用你的账号，能力上限极高；artux 让一家公司拥有一支可被交办、可被审计、经验留在公司的数字员工队伍——它跑在企业专属实例上，接企业的飞书、企业的业务系统，产出属于组织。 artux 的运行时本身就构建在 Claude 系模型之上，这不是巧合：把一个已经很强的个人 agent 变成企业能"雇佣"的员工，缺的从来不是模型能力，是雇佣关系需要的那一整套东西——身份、权限、记忆归属、成本可见、审计留痕。
Claude Code 是什么？
Claude Code 是 Anthropic 官方的编程 agent。它以 CLI 的形态跑在终端里，也有桌面应用、网页版和 IDE 扩展。它能读写文件、执行命令、搜索代码库、调用 MCP 工具、派发子 agent，并通过 skills 和 hooks 让你把团队的规范固化进去。同一套 harness 还被打包成 Claude Agent SDK，供开发者构建自己的 agent。
它的定位很清楚：给一个懂技术的人，一个极强的助手。 这个定位带来两个特征：
- 能力上限由使用者决定。会用的人能让它连续工作几十分钟完成一次跨文件重构；不会用的人只能拿它补全函数
- 它跑在使用者的机器上、用使用者的凭据。这是它强大的原因（能碰到真实环境），也是它的边界所在
artux 在做什么不一样的事？
artux 面向的不是"一个懂技术的人"，而是一家公司里不写代码的大多数——销售、运营、财务、客服、供应链。他们不会开终端，也不该被要求开终端。
所以 artux 的入口不是命令行，是飞书。员工在原本聊天的地方 @ 一下就是派活；总管理解意图后派给对应岗位——市场分析师取数、协同办公专员建表、运维工程师巡检——做完把成果送回来。员工只说要什么，不用指定该找谁。
更根本的差异在于这台机器是谁的。artux 是一企业一实例：每家客户一套独立的服务与数据，不与其他客户共用数据库，跑在云服务器或我们的自有机房，由我们运维。客户经平台界面操作，碰不到代码和实例机。
为什么 artux 构建在 Claude 系模型之上？
因为长任务的可靠性、工具调用的准确性、以及"做不到的时候会如实说"这三件事，是数字员工能不能上岗的前提，而这三件事高度依赖底层模型的质量。
artux 支持三种 AI 供给方式，客户按合规与成本需求选：
| 供给方式 | 说明 |
|---|---|
| 平台托管（Bedrock） | 由平台统一供给，客户不接触 Key；可选模型由平台策展并受套餐约束 |
| 自带 API Key | 客户用自己的 Anthropic 账号；配了 AI 凭据网关时实例只拿网关地址与令牌，真 Key 不落地 |
| 订阅账号令牌 | 通过 OAuth 流程写入，适合已有 Claude 订阅的团队 |
第二种的实现细节值得单独说：常规做法是把 API Key 明文写进实例环境变量——实例被入侵、镜像被误传、日志被打印，Key 就跟着漏了。artux 的实例上写的是网关令牌而非真 Key，需要时向网关换取。出问题时撤销的是那台实例的令牌，不是你的账号密钥。
个人 agent 和企业数字员工的五条分界
这五条是"能力"之外的东西，也正是从 Claude Code 到 artux 之间隔着的距离。
① 用谁的身份 Claude Code 用你的账号、你的 SSH key、你的浏览器登录态。这对个人是效率，对组织是风险——它做的每件事在审计里都记在"你"头上，出了问题分不清是人还是工具。artux 用企业自建应用的机器人身份说话；访问业务系统时，网关以"发起人本人"身份铸造受限凭证，请求穿过既有的权限体系由业务系统在源头鉴权。权限不复制、不镜像，唯一真相源在业务系统——结果是数字员工永远读不到这名员工本人无权看的数据。
② 记忆归谁 你在 Claude Code 里积累的 CLAUDE.md、skills、调好的提示词，留在你的仓库和你的机器上。人走了，这部分能力跟着走。artux 的记忆按归属切成三棵树：员工档案树（每人一棵，你的偏好换谁服务都认得）、岗位经验树（每岗一棵，情报采集岗的抓取技巧协同办公岗检索不到）、平台认知树（编制名册与通道状态）。检索在数据库层就限定范围——拿不到别人的数据，而不是拿到后再过滤。
③ 谁在等它 Claude Code 是你敲下回车它才动。数字员工要在没人说话的时候工作：每天 07:30 跑动销测算、价格异动主动通知、跨群汇总经营简报。受阻时登记一笔承诺，记下恢复条件与预计时间，条件满足后自动重做并如实告诉员工。个人 agent 与企业 agent 的完整分界，见《为什么企业还需要数字员工平台》。
④ 谁能看见花了多少钱 个人工具的成本落在个人账单上。组织需要知道哪个岗位、哪类任务消耗了多少额度。artux 按席位 + token 额度计价（标准版 ¥899/月，含 10 席 + 10M token，全部档位见定价页），额度归属清晰。
⑤ 出错时能追到哪一层 "AI 又出问题了"不是可运维的粒度。artux 的每一次派发、每一次重试、每一笔承诺、每一条记忆写入都留痕；运营能在控制台里翻看数字员工记住了什么，发现错误记忆可直接标记作废（立墓碑而非裸删），操作归责到人。
一个公司同时用两者的典型分工
这不是二选一。我们自己就是这么用的：
- 工程团队用 Claude Code 写代码、做重构、跑 code review。它跑在工程师本机，接触源码，能力上限最高
- 全公司用 artux 处理跨系统的重复劳动：市场调研、动销测算、竞品监控、多语言 listing、服务器巡检
分界线可以用一句话判断：这件事需要一个懂技术的人在旁边看着吗？ 需要 → 个人 agent。不需要、而且希望它每天自己跑 → 数字员工。
那企业能不能自己拿 Claude Agent SDK 搭一套？
技术上完全可以，而且这条路是通的——artux 本身就是这么长出来的。但要评估的不是"能不能搭出一个能跑的 agent"（那部分现在很快），而是搭出之后剩下的那些：
- 多租户信息隔离（合库的隔离性从"物理上不可能泄漏"降级成"依赖每一行查询都写对过滤条件"）
- 凭据不落地（Key 在实例上明文放着，等于把风险交给运维纪律）
- 记忆的归属切分与改口机制（"记住"容易，"改主意不留矛盾记录"难）
- 常驻实例的开通、升级、健康上报、备份与回滚
- 席位与额度的计量
这些不是模型问题，是工程问题——它们占掉的时间远多于"接一个 agent"。我们自己花了 12 个月走完这条路，artux 是这套实践的产品化——过程写在《一家跨境家具公司的 12 个月 AI 自研之路》。
FAQ
artux 能替代 Claude Code 吗？
不能，也不打算。写代码这件事，工程师直接用 Claude Code 效率最高。artux 里的电商技术工程师岗位做的是另一件事——按运营的自然语言需求改站、推预览主题、双视口截图自检、交预览链接、确认后才推 live，把工程能力交付给不写代码的人。
我已经在用 Claude Code 了，artux 对我有什么增量？
增量在"你不在的时候"和"不是你的时候"。定时任务、主动推送、跨群简报是前者；让运营和财务也能用上同一套能力、且经验沉淀回公司是后者。
artux 用的具体是哪个 Claude 模型？
取决于供给方式与套餐。平台托管模式下可选模型由平台策展；自带 Key 与订阅模式下由客户在配置页选择。我们的原则是不超卖——能力矩阵里写 stable 的就是今天真的稳定，写 limited 的就标明限制在哪。
数据会不会流到模型提供方？
模型推理不可避免要发送对话内容给模型服务，这是所有 LLM 产品的共同前提。artux 能控制的是其余部分：记忆、任务、审计全部落在你专属实例的本地数据库与磁盘；语义检索用的向量模型在进程内本地推理，不调外部 embedding 接口——调用外部接口等于把员工对话逐条发出去。
能私有部署吗？
不能，这是刻意的。所有实例跑在我们自己的基础设施上（AWS 或自有 Mac 机房），客户只经 artux.ai 管理界面操作，碰不到代码和实例机。代码不外发。