artux 不是套壳，也不是把几个开源 agent 项目拼起来加个界面。三套系统——数字员工运行时、云控制面、训练与评测体系——全部自研，从 2025 年 8 月的第一次提交走到今天，12 个月。同时我们把话说清楚：基座模型不是我们训练的，也不打算训练。 我们自研的是模型之上的全部工程——多智能体编排、租户隔离与实例开通、凭据托管、IM 深度集成、记忆归属与改口机制、审计与闸门、岗位训练体系。这段自主换来的不是"技术很牛"这种形容词，而是三件可以写进合同的具体事：数据零出网敢承诺、出问题能自己修完、能力迭代不看别人脸色。 下面把每一件的来龙去脉讲完。
先说清楚：我们自研什么，不自研什么
这一节放在最前面，因为"全自研"是个很容易被滥用的词。
不自研的：基座模型。 artux 的运行时构建在 Claude 系模型之上，支持三种供给方式：平台托管（Bedrock）、客户自带 API Key、订阅账号令牌。训练一个前沿基座模型是另一个量级的生意，我们没有那个规模，装作有才是不诚实。artux 是独立产品，与模型厂商无从属或背书关系。
自研的：模型之上的全部工程。 这句话具体展开是三套系统：
| 系统 | 是什么 | 解决的问题 |
|---|---|---|
| 数字员工运行时 | 总管 + 专业岗位子代理的编排内核、飞书深度接入、真实浏览器操作、长期记忆 | 让一个 agent 变成一支有分工的团队 |
| 云控制面 | 租户与订阅、实例自动开通与升级、AI Key 托管与分发、网关与中继、席位与额度计量 | 让这支团队能被成百上千家企业各自拥有一份 |
| 训练与评测体系 | 岗位手册、技能包、知识库、行为评测与报告 | 让它真的懂业务，而不只是会说话 |
为什么第三套也算系统：多数人以为把 agent 做出来就完了，实际上"教会它干这行的活"是独立且更耗时的工程。在我们自己的实践里，这部分沉淀成 59 个技能包、81 篇知识库文档、2.2 万行岗位手册——这是把公司的 SOP 教给 AI 的过程，它不在任何开源项目里。
时间线：每个节点都是 git 的真实首次提交日期
这条线不是事后画的路线图，是仓库里的提交记录：
| 日期 | 节点 |
|---|---|
| 2025-08-01 | 自研起点——运营中台第一次自有提交 |
| 2025-12-10 | AI 生图平台立项，第一个真正意义上的 AI 能力；同日第一个自研 Shopify App 上线 |
| 2026-01-22 | 飞书打通——组织架构、登录、消息卡片链路建立 |
| 2026-02-27 | 运维与安全体系建立，7 台服务器纳管 |
| 2026-04-20 | 数字员工体系立项——AI 从"工具"变成"同事"的组织化拐点 |
| 2026-06-02 | GEO 工作站立项，首日即完成骨架 + 9 个数据连接器 + 审计规则引擎 |
| 2026-07-09 | 数字员工网关上线——act-as-user 机制，以"你本人"的权限访问中台 |
| 2026-07-14 | GEO 工作站正式部署，多用户多站点权限体系同步就位 |
| 2026-07-26 | GEO 自动化调度器全量落地：单日 12 任务 / 26 提交 / 82 文件 / +11,801 行，红线检查 5/5 通过 |
2026-04-20 是分水岭。 在那之前做的是"让系统替人算"，在那之后做的是"让系统替人跑"。这两件事需要的工程量完全不在一个量级——前者的边界是算得对不对，后者的边界是它在没人看着的时候会不会闯祸。
工程侧的规模，按白皮书口径（数据截止 2026-07-27）：数字员工体系本身 9 万行代码 / 224 个测试文件 / 318 个数据库迁移 / 503 次提交，49 个接口模块、36 个管理视图支撑这支团队日常运转。这个数字要和另一个数字分清楚：五大自研体系合计 123 万行（精确值 1,227,041 行）是包含运营中台、Shopify 生态、GEO 工作站等在内的总和，不是 artux 一家的代码量。混着说会好看很多，但那是另一回事。完整的体系账本在《一家跨境家具公司的 12 个月 AI 自研之路》。
自主换来的第一件事：数据零出网，敢写进承诺
"数据不出网"是所有企业 AI 产品都会说的话。区别在于敢把这句话拆到哪一层。
拆到底是这样的：
- 一企业一实例：每家客户一套独立的服务与数据，不与其他客户共用数据库。合库能省成本，但隔离性就从"物理上不可能泄漏"降级成"依赖每一行查询都写对过滤条件"
- 语义检索不出网：同义联想需要向量模型，我们让它在进程内本地推理，不调外部 embedding 接口。调外部接口等于把员工对话逐条发出去。代价是本地小模型表达力弱一些，所以设了双重相似度闸门兜住不确定性
- 凭据不落实例：AI 与应用密钥留在云网关，永不落到实例上，可按实例单独吊销
- 权限由业务系统源头鉴权：网关不重写鉴权，以"发起人本人"身份铸造受限凭证，请求回环打进业务系统，穿过既有的权限体系。权限不复制、不镜像，唯一真相源在业务系统
这四条里的每一条，都要求你拥有那一层的代码。 如果编排内核是别人的，你不知道它在什么时候把上下文发去了哪里；如果 embedding 走的是第三方接口，"不出网"就只能是一句形容词。自主不是目的，是这些承诺能成立的前提。
第二件事：出问题能自己修完
拼装形态最贵的成本不是许可费，是故障停在别人的排期上。
自研的直接结果是每一层都能改。举一个真实的例子：公开预览链接对未登录浏览器会丢参数跳主域——数字员工改完主题去截图自检，截到的其实是线上页面而不是预览页，"验证过了"是假的。这类问题不会出现在任何文档里，只能自己踩、自己定位、自己把自检链路改成走本地服务。如果那一层是黑盒，你连"截错了"这件事都发现不了。
同样的道理支撑着可运维性。"AI 又出问题了"不是可运维的粒度，我们要求定位到具体环节：哪一次派发选错了岗位、哪一次工具调用超时、哪一条记忆写错了、哪一笔承诺没兑现。所以每一次派发、每一次重试、每一笔承诺、每一条记忆写入都留痕；运营侧的写操作强制归责到人，无身份的请求直接拒绝。
记忆的撤回也做了额外的一层：不是裸删，而是立"墓碑"并在 30 天内主动告诉 agent"这条已作废，勿引用"——因为单纯删掉记录管不住当前会话里已经形成的旧印象。这种细节没有产品经理会提，是被真实故障逼出来的。
第三件事：能力迭代不受上游制约
一个具体的取舍能说明问题：我们把红线写进类型系统，而不是写进提示词。
调度器只接受"采集 / 分析 / 巡检"三类任务，刻意不定义"写"类型——任何写生产站点或发布内容的任务，在注册阶段就会被拒绝，并有单元测试常驻断言。把"不能做"变成类型系统里不存在的东西，比写在提示词里可靠得多：提示词会被绕过，类型不会。
这个设计只有在编排内核是自己的时候才做得出来。同一类的还有：
- 上线前的人工闸门：数字员工改完主题只能推预览主题 + 双视口截图（PC 1440×900 / 移动 390×844）+ 预览链接，然后停下，必须等运营明确回复"确认上线"
- 回写六铁律：幂等键防重复 · 二次确认才真写 · 写前快照 · 一键回滚 · 全链路审计 · 失败进死信队列
- 事实 ≠ 权限：记忆里写着"某人拥有最高权限"只影响 agent 怎么理解对话，不影响它能做什么——这是防提示注入的关键
- 能力如实标注：能力矩阵每一项都标状态，取不到的字段留空并说明，不做估算填补
最后一条值得多说一句。能力清单上写着 stable / limited / unsupported / roadmap 四种状态，Google SSO 登录标 limited（可能被机器人检测拦住），微信系与依赖设备指纹的应用标 unsupported。一个会如实说"做不到"的员工，比一个什么都答应的助手更可用——这条我们宁可少卖一些也不改。
那为什么不直接用开源方案拼？
这是最该被认真回答的问题，因为路确实是通的，我们也不打算说反话。
开源 agent 生态今天非常成熟，搭一个能跑的 agent 很快。真正吃掉时间的是搭出来之后剩下的部分：
- 多租户隔离与实例的开通、升级、健康上报、备份、回滚
- 凭据托管与按实例吊销
- 记忆的归属切分（员工档案树 / 岗位经验树 / 平台认知树）与改口机制——同一条记忆原地更新并保留旧值，而不是再记一条让库里躺着两条矛盾记录
- IM 深度集成：不只是收发消息，还有多维表格读写、云文档与知识库、任务与日历、卡片式进度回传
- 席位与 token 计量、成本归因
- 全链审计与执行路径上的闸门
这些都不是模型问题，是工程问题。而工程问题一旦被解决一次，就可以被复用——这也正是我们把它做成产品的理由。个人与团队之间那道缺口的完整拆解，写在《OpenClaw 很好用，然后呢？》。
为什么是我们来做这件事
市面上做 Agent 的公司很多，做 SEO 工具的也很多。但要把一条 DTC 全链路的 SOP 教给数字员工，前提是这家公司自己真正跑通过这条链路——知道选品卡在哪、知道补货算错的代价、知道主题改错一行 CSS 会让转化掉多少、知道结算页被机器人刷是什么感觉。
这些经验没法从文档里学，只能从踩过的坑里长出来。
所以 artux 不是先有产品再找场景，而是反过来：先有一家公司每天在用，用出问题，改，再用。这套体系我们自己每天在用，它还在长。
FAQ
artux 是不是某个开源 agent 的套壳？
不是。运行时是自研的多智能体编排系统，与主流开源个人 agent 项目没有代码关系。会被这么问是因为形态上有共同点——agent 住在 IM 里、有长期记忆、能操作真实环境——但这恰恰说明这条路径是行业共识，不说明谁抄了谁。真正的差别在形态之下：多租户隔离、凭据不落地、记忆按归属切分、执行路径上的闸门，这些在个人 agent 的设计前提里根本不存在。
既然模型是外采的，"自主可控"这个词还成立吗？
成立，但要限定在正确的范围里，所以我们把边界写在文章第一节而不是藏在末尾。模型是能力来源，工程是控制来源。 数据落在哪、谁有权访问、失败了怎么办、能不能审计、红线怎么执行——这些全部由工程层决定，而工程层是我们自己的。反过来说，如果这一层是别人的，那么无论底下换成哪个模型，你都谈不上可控。模型侧我们保留三种供给方式（平台托管 / 自带 Key / 订阅令牌），本身也是为了不被单一通道卡住。
自研 12 个月，会不会比用现成方案落后？
在"接一个 agent 让它能对话"这件事上，我们不比任何人快，也不需要快。差距体现在另一端：别人从 demo 到能交付给企业的那段路，我们已经走完并且在生产环境跑了一年。 客户拿到的是走完之后的结果，不是这 12 个月。
这些技术细节我怎么核实？
三个可核对的入口：能力清单逐项标注状态（stable / limited / unsupported / roadmap），刻意不夸大，请以此页为准而不要从营销文案推断；定价页的价格与币种以 Stripe 实配为真相源；7 天全功能试用（审核制，5 席 + 300 万 token）可以直接验证。建议用试用期跑一个你现在真的每天在人工做的活，而不是跑演示场景——后者看不出差别。
一家没有工程团队的公司，能不能复制这条路？
自研这条路需要工程投入，这是实话。artux 的存在就是为了让不需要重走这 12 个月的公司直接拿到结果——一企业一实例，注册后审核开通，飞书里配好凭据（约十分钟 + 组织内审批）就能派活。
代码在你们手上，客户会不会被锁定？
形态上确实是代码不外发、客户经平台界面操作，不存在"客户自部署"——这一点我们说在前面。降低锁定风险的是另外两件事：业务知识与规则是可导出的（岗位手册、技能包、知识库本质上是你自己的 SOP），以及我们不碰你的业务系统权限（数字员工以发起人身份访问，由你的业务系统源头鉴权，随时可以在你那侧收回）。真正被锁在里面的东西，我们尽量做到没有。