账本架构：用 Grok Bot + Kimi K3 运营六个业务（完整搭建）

Ledger Architecture: Running Six Businesses on Grok Bot + Kimi K3 (Full Build) 2026年8月27日 · 16 分钟阅读 · 查看来源 ↗ Grok Bot Mobile Apps MCP Advertising 每个生意都有自己的智能体，每个数字都有负责人，任何动钱的事都停在你面前 为什么是这对组合，而不是二选一 Grok Bot 是成品画面。你像给队友一样给有名字的 bot 发消息，它们共享一台带浏览器、文件系统和终端的持久云端机器，它们保持登录着你的真实工具，而且在你合上笔记本后继续工作。 Kimi K3 是零件箱。开放权重、一个真正有手的编程智能体、skills、MCP、子智能体和 SDK。没有东西藏在订阅层级后面，而组织架构图始终是你的。 大多数人把它当成二选一。它不是。Grok Bot 是感受一个运转中的团队是什么样最快的方式。Kimi K3 是你重建那个团队、让它属于你、并扩展到超过一个账号的方式。 这些生意不关心你用哪个。它们关心的是有人拥有那个数字。 安装 Kimi K3 让我先破一个迷思。Kimi K3 不是笔记本安装。它是一个 2.8 万亿参数的开放权重 MoE 模型，每个 token 约 104B 活跃，跨 896 个专家，原生视觉，以及一个 1,048,576 token 的上下文窗口。官方 MXFP4 检查点大约在 1.5 到 1.6 TB。官方 vLLM 配方从 8× B300 / GB300 级 GPU 起，或 AMD MI355X 等价物。 任何叫你"直接下载"的人，都没看过文件大小。 官方链接 GitHub: https://github.com/MoonshotAI/Kimi-K3 Hugging Face 上的权重: https://huggingface.co/moonshotai/Kimi-K3 API 快速入门: https://platform.kimi.ai/docs/guide/kimi-k3-quickstart 模型名 kimi-k3，OpenAI 兼容 Kimi Code: https://www.kimi.com/code 路径 A - 你第一天真正想要的那个 用托管模型。kimi.com 上的网页和移动应用，或 API。零基础设施，完整 K3，今天就开始。 路径 B - Kimi Code CLI，那双手 这是把答案变成工作的东西。它读取和编辑文件、运行 shell 命令、抓取页面、并从它发现的东西里挑出自己的下一步。 # macOS / Linux curl -LsSf https://code.kimi.com/install.sh | bash # Windows Invoke-RestMethod https://code.kimi.com/install.ps1 | Invoke-Expression 然后登录并选择模型： kimi /login /model # choose Kimi K3 路径 C > 自托管开放权重 只有当你有时才有意义。README 里的官方引擎：vLLM、SGLang、TokenSpeed pip install -U huggingface_hub hf download moonshotai/Kimi-K3 --local-dir ./Kimi-K3 vllm serve moonshotai/Kimi-K3 \ --tensor-parallel-size 8 \ --trust-remote-code \ --load-format fastsafetensors \ --enable-prefix-caching \ --enable-auto-tool-choice \ --tool-call-parser kimi_k3 \ --reasoning-parser kimi_k3 完整配方：https://recipes.vllm.ai/moonshotai/Kimi-K3SGLang cookbook：https://docs.sglang.io/cookbook/autoregressive/Moonshotai/Kimi-K3 社区 GGUF 和 Unsloth 量化版存在，用于本地运行，仍然是数百 GB 的 RAM 或 VRAM：https://unsloth.ai/docs/models/kimi-k3 。CPU 移植版是概念验证，不是生产速度。 我的建议：从 API 开始。只有当你的 token 账单超过你的 GPU 账单时才转向自托管，而你会确切地知道那何时发生，因为你会一直盯着它。 安装 Grok Bot 这里没有长指南，而这正是重点。去网站、下载、登录。 > https://x.ai/bot 访问权限与更高的 xAI 层级捆绑，而不是单独售卖，所以在付两次钱之前，先检查你当前套餐已经包含了什么。 在把任何组织架构图复制上去之前，有两件事要知道： 一台机器，多个 bot。你创建的每个 bot 共享一台绑定到你账号的持久云端电脑，而不是绑定到单个 bot。这正是它们能把文件、浏览器会话和登录互相移交的原因。这也是敏感凭据不属于那台机器的原因。 有上限。bot 和群聊按账号有上限，而 xAI 自己的文档告诉你在加另一个之前先想想。好建议。每多一个 bot，就多一个要调试的东西。 六个生意，六本账本，一张桌子 这是人人都搞错的部分，所以我要直说。 你不是在构建六个聊天机器人。你在构建六本账本，每本有一个负责人。 一本账本是一个生意的完整状态：进来了什么、进行中什么、交付了什么、收到了什么付款、坏掉了什么。一个拥有一本账本的智能体，不是在回答关于这个生意的问题。它是对账本底部那个数字负责的东西。 这六个 # 生意 智能体 拥有数字 从不做 1 内容工作室 ECHO 已发布内容、触达、列表增长 从不推销、从不开发票 2 电商店铺 CRATE 已发货订单、每个 SKU 的毛利 未经批准从不改价 3 服务代理 PITCH 已约见电话、已签合同 从不交付工作 4 数字产品 VAULT 已售份数、退款率 从不投付费广告 5 线索生成 BEACON 已交付合格线索 从不谈判费率 6 社区/会员 HEARTH 活跃会员、流失 从不发放积分 — 桌子 WARDEN 路由、现金、优先级 从不碰工作本身 读最后两列，不是前两列。生意是可替换的。拒绝才是设计。 WARDEN 不是公司意义上的经理。它是一个带现金视角的调度员。它从不写文案、从不打包订单、从不参加销售电话。它唯一的工作是决定哪本账本接下来得到关注，并拦下任何动钱的事。 YOU │ approvals only │ WARDEN routing · cash · priorities │ ┌──────────┬──────────┬───┴───┬──────────┬──────────┐ ▼ ▼ ▼ ▼ ▼ ▼ ECHO CRATE PITCH VAULT BEACON HEARTH content store agency products leadgen community │ │ │ │ │ │ cms supplier crm gumroad scraper discord social shipping calendar stripe dialer stripe analytics ads mgr docs support enrich email 三条防止烧钱的规则 我见过很多人把六个智能体接在一起，最后得到一个会花钱的群聊。这三条规则是桌子与一团糟的区别。 规则 1 - 任何动钱的事都要两把钥匙 没有任何单个智能体能完成一个资金动作。永远不。 一个智能体提议，一个不同的智能体对照账本核实，你按按钮。三个分离的上下文，没有一个能跳过另外两个。 CRATE: "reorder 400 units of SKU-118, supplier invoice 2,940" ↓ WARDEN: checks cash on hand, checks 30d sell-through, checks open POs ↓ PASS with note: "cash covers it, sell-through 71%, no open PO on 118" ↓ YOU: approve / hold / kill 如果 WARDEN 无法从账本核实一个数字，请求就死掉。它不会自己去翻那个数字。一个缺数字的提议是一个坏掉的提议，不是一个要解的谜。 规则 2 - 每个动作有个颜色，而颜色在代码里强制执行 不在 prompt 里。prompt 是建议。代码是墙。 GREEN 独自运行，通宵，没人问 读收件箱 · 起草一篇帖子 · 给线索打分 拉分析 · 给工单打标签 · 写进临时文件 AMBER 运行，然后在落地前报告 排期一篇帖子 · 更新产品描述 回复一张支持工单 · 移动一个交易阶段 RED 完全停下，等人 发钱 · 改价 · 发布付费广告 给客户清单群发邮件 · 发退款 · 删除记录 取消供应商订单 人们掉进的两个坑。 取消是红的。人们把取消归档在"撤销"下，而它们不是。在你已售出的库存上取消的供应商订单是一个洞，而且没有"反取消"按钮。 读取可以是红的。一个凌晨 2 点烧掉你 API 配额的爬虫，会耗掉你共享那个 key 的生意接下来的四个小时。 这是它作为配置而不是好意长什么样： { "permissions": { "allow": [ "read_*", "grep", "mcp__analytics__*", "mcp__crm__read_*", "mcp__store__read_*" ], "ask": [ "mcp__cms__schedule_post", "mcp__crm__update_stage", "mcp__support__reply" ], "deny": [ "mcp__bank__transfer", "mcp__store__set_price", "mcp__ads__set_budget", "mcp__mail__blast", "mcp__store__cancel_order", "mcp__db__delete_*" ] }, "hooks": { "preToolUse": "./guards/colour_check.sh" } } deny 不是 ask。deny 列表存在，是因为凌晨 1 点你会批准你不该批准的东西。把这个选项从你未来疲惫的自己手中拿掉。 审批会过期。一张没人二十分钟内回复的审批卡会死掉，并记录自己为已过期。错过一次机会让你损失一点。在六小时前就过时的上下文上执行，让你损失很多。 规则 3 - 每个断言携带它的来源，否则交接弹回 一旦智能体把数字互相传递，凭空捏造的数字就会以机器速度流经你的生意。 把它做成结构性的，而不是一个判断： { "claim": "SKU-118 sell-through 71% over 30d", "value": 0.712, "source": "mcp://store/reports/sellthrough?sku=118&window=30d", "read_at": "2026-08-27T09:14:02Z", "produced_by": "crate", "ledger": "ecom" } 一个无来源的数字现在是一次 schema 违规。它在到达 WARDEN 之前就失败了，而 WARDEN 永远不必决定是否信任它。 正是这一条规则让我不再手工反复核对。那份反复核对税从不出现在任何人的演示里，而它吃掉整个时间节省。 智能体实际上如何互相交谈 六个独立智能体是六个生意。互相交接工作的六个智能体是一家公司。区别在布线。 每日循环 每本账本跑同样的三拍节奏。同样的时钟，不同的工作。 07:00 晨间拉取 每个操作者读它自己的世界并写一行状态 ECHO → 发布了什么、表现如何、排队着什么 CRATE → 昨夜订单、库存水平、供应商消息 PITCH → 回复、已约见电话、冷掉的交易 VAULT → 销售、退款、支持问题 BEACON → 已打分新线索、交付配额状态 HEARTH → 加入、取消、未回复的帖子 WARDEN 读六行状态并写一份优先级清单 12:00 午间构建 操作者只做他们的前两项 任何 amber 的排队，任何 red 的进卡 18:00 晚间结算 每本账本以一个数字和一份异常清单收尾 WARDEN 为你产出一份简报 你大约十分钟清完卡队列 交叉布线 钱就藏在这里，而这是几乎没人构建的部分。 你的六个生意不是六座孤岛。它们互相喂食，而智能体应当自动路由那份流量。 ECHO publishes a piece that pulls unusual traffic └─→ BEACON tags the inbound as warm, scores it └─→ PITCH gets the qualified ones as booked call candidates └─→ signed client goes to HEARTH for onboarding └─→ HEARTH sees which questions repeat └─→ VAULT turns the top three into a paid product └─→ ECHO writes the launch content └─→ loop closes, and it is warmer than last turn 那个循环才是真正的生意。本文其他每一部分都是让这个循环能被无人值守安全运行的管道。 CRATE 略微站在它外面，喂的是现金而不是线索： CRATE margin ──→ WARDEN cash view ──→ funds ad tests for VAULT └──→ funds BEACON data spend 一次交接在线路上长什么样 { "from": "beacon", "to": "pitch", "kind": "qualified_lead", "priority": "high", "payload": { "company": "Northline Freight", "trigger": "posted 4 ops roles in 14 days", "fit_score": 0.81, "evidence": [ "mcp://jobs/search?company=northline&window=14d", "mcp://crm/history?company=northline" ] }, "expires_at": "2026-08-28T09:00:00Z" } 注意 expires_at。线索会腐烂。一个没有过期的交接变成一队陈旧的工作，某个智能体最终会在最糟的时刻去执行。 路由在代码里执行组织架构图，不在 prompt 里 prompt 里的礼貌不是控制。把它放进代码： def route(task, desk): owner = desk.owner_of(task.ledger) # nobody executes on money without a second pair of eyes if task.colour == "RED" and not desk.has_verification(task.id): return card_to_human(task, reason="red action, awaiting your call") # a claim without a source never travels if not desk.evidence_complete(task.id): return bounce(task, to=task.origin, reason="missing source on a number") # operators only see their own slice return dispatch(owner, task, desk.slice_for(owner)) desk.slice_for(owner) 是整个系统里安静的主角。PITCH 从来看不到电商账本。CRATE 从来看不到客户清单。一个智能体无法被说服去滥用它从未被交到手上的数据。 编写智能体 一个 prompt 描述这单一任务。一份章程（charter）描述这个席位。你要的是章程。 在 Kimi Code 里这些是 skill 文件，当工作匹配时自我加载。 --- name: crate-ops description: Owns the ecommerce ledger end to end whenToUse: Anything touching orders, stock, suppliers or SKU margin --- # CRATE — Store Operator ## Owns Orders shipped, stock cover, margin per SKU, supplier comms. The number: contribution margin this week. ## Refuses Never sets or changes a price. Never cancels a supplier order. Never runs or edits ads. Never emails the customer list. ## What good output looks like A daily state line with four figures, each carrying a source: orders, stock cover in days, margin, exceptions. Exceptions are named, not summarised. ## Hard limits Reorder proposals above 3,000 always go to WARDEN with cash context. Any SKU below 10 days of cover is an exception, not a note. Any supplier reply older than 48h without an answer is an exception. ## Rules If a number is missing, say which one and stop. Do not estimate margin. Pull it or flag it. If two data sources disagree, report both and do not pick. 最后那条规则比它看起来更重要。一个在两个冲突数字之间悄悄挑一个赢家的智能体，是一个已经开始捏造你生意结果的智能体。 先写拒绝。每一次都如此。如果你写不出一个席位绝不能做的三件事，这个席位还不存在，你只是有一个模糊的助手。 现在，钱的对话 关于这一节我要对你诚实，因为大多数这个主题的帖子不诚实。 这些是模型数字，不是收据。它们展示这个结构如何到达六位数，以及要让它们成立必须为真什么。你的市场、报价和成交率决定它是否成立。把它当作一份可以争论的算术，而不是一个承诺。 一个月 10 万块横跨六本账本的一个现实形态： 服务代理（PITCH） 8 个合同 × 4,500 = 36,000 数字产品（VAULT） 620 份 × 39 = 24,180 电商（CRATE） 1,400 单 × 14 毛利 = 19,600 线索生成（BEACON） 3 个客户 × 3,500 = 10,500 社区（HEARTH） 410 会员 × 19 = 7,790 内容工作室（ECHO） 赞助 + affiliate = 4,800 ------- 102,870 ECHO 赚得最少，却是桌子上最重要的席位。它喂着其他每一本账本。用它往下游送了什么来评判它，不是用它开了多少账单。 成本侧，全程走 API： 六个账本的模型用量 900 - 1,600 / 月 工具、托管、数据、订阅 400 - 700 / 月 Grok Bot 访问（捆绑层级） included ------------------ 1,300 - 2,300 / 月 有意思的数字不是毛利。是每个已完成任务的成本，因为那才是告诉你何时切换计费模式的东西。从第一周就开始追踪它。超过某个量阈值后，固定订阅胜过按 token 定价，而没有你自己的数据，你找不到你的阈值。 真正有效的构建顺序 别构建六个智能体。你会花一个月调试一家没有客户的公司。 第 1 周 一本账本。那个已经在赚钱的。 通过 Kimi Code 手工运行它的任务并观察。 写下它每一处卡住或猜测的地方。 那份清单就是你的第一份章程。 第 2 周 给那本账本里的每个动作上色。 把 green、amber、red 放进 permissions 和一个 preToolUse 钩子。 故意弄坏它。试着让它花钱。修掉泄漏的地方。 第 3 周 第二本账本，加上 WARDEN。 两个操作者才是路由开始要紧的地方。 现在就把证据 schema 建好，别等六个席位都依赖它。 第 4 周 在两个之间接上第一个交叉交接。 只一个方向。证明它无需你就能搬动工作。 第 5-6 周 账本三和四。复用章程模板。 后一半比前一半快得多。 第 7 周 SDK 封装和日程。 现在它夜里跑，你早上查队列。 第 8 周 账本五和六，只有当四个账本在没有你打开终端 的情况下完整跑了一整周之后。 from kimi_agent_sdk import Agent, Session desk = Session( work_dir="./desk", skills=["warden", "echo", "crate", "pitch", "vault", "beacon", "hearth"], mcp_servers=["store", "crm", "cms", "mail", "analytics", "stripe"], ) run = Agent(session=desk).run( task="Run the evening close on all six ledgers. Card anything red.", require_approval=[ "mcp__bank__transfer", "mcp__store__set_price", "mcp__ads__set_budget", "mcp__mail__blast", ], ) for event in run.events: if event.type == "approval_requested": push_card(event) # your queue, your expiry, your decision 失败清单 下面每一条都为某个人弄坏了某样东西。在构建之前读它，不是之后。 每个生意一个智能体，不是每个工具一个智能体。工具形状的智能体会增殖，直到你有二十个要调试的东西，却没人拥有一个数字。 调度员绝不能做工作。WARDEN 一旦开始写文案，它就无法再对任何事说不。 没有智能体修复另一个智能体的坏输入。它拒绝它并说出缺失的字段。修复会永远隐藏坏掉的上游。 共享凭据是共享的爆炸半径。Grok Bot 每账号一台机器，对交接是特性，对 key 是风险。按账本限定凭据范围。 每个席位用同一个基础模型，是一个盲点。如果它们都同样地推理，它们就都同样地错过。诚实的修复是在核实椅上放一个不同的模型。 一个被污染的数据源同时打中几个账本。如果 BEACON、PITCH 和 WARDEN 都信任同一个信息流，一个坏信息流会产出自信的一致，而不是抓住它的分歧。 协调变难的速度快于产出变好的速度。六不是魔法，它是最小的数字，让每一种危险能力都坐在不同的椅子上。只有当第六个变得无聊时，才加第七个。 要点 你真正在构建的，不是六个 AI 工人。是一张桌子，每个数字都有负责人、每个断言都有来源、而动钱的一切都停在一个人面前。 模型比人们想的更不重要。K3 给你推理能力和容纳一整个生意日的上下文窗口。Kimi Code 给它双手。Grok Bot 在你把它建出来之前，就让你看见成品摸起来是什么感觉。 组织架构图就是产品。六个智能体、六本账本、一张桌子，和一条你每天十分钟清空的队列。 那就是当你没人在看、除了你自己时，运营六个生意的样子。 如果这对你有用，我每隔几天就发这样的拆解。标签：# X # Grok Bot # Mobile Apps # MCP # Advertising # Ecommerce # Mobile Apps # AI # Guide # Affiliate 相关文章 How I use Grok Bots to rank brands on AI answers that it feels illegal Name this bot `CrowdReply - Scout`. Grok Bot AI MCP Slack