系统崩溃归因：从内核到内存的五层收敛法

导语：崩溃分析真正的工作量不在「找到崩溃的那个函数」，而在证明它不是根因。

崩溃报告给出的，几乎总是发现故障的位置，而不是造成故障的位置。

内核是个诚实的证人，但它的证词有偏差：它只在踩到非法内存的那一刻报警。而那块内存可能几毫秒前、也可能十几分钟前就被别人写坏了；那个对象可能早已被回收，指针只是还挂在某个链表上。所以崩溃点天生在下游，根因在上游，两者之间隔着一段时序。

这决定了排查的基本形状：不是去找「谁崩了」，而是沿时间往回退，直到找到一个能被证据钉住、又能被实验证伪的环节。

下面这套分层方法，是我在一次真实的蓝屏排查中逐步磨出来的。它不是检查清单的堆叠，而是一条证据粒度越来越细的收敛链。

五层漏斗：每层只回答一个问题

层与层之间不是并列关系，而是上下游关系。上层的产物是下层的输入，判据是「是否产出一个能被下一层消费的锚点」。没有锚点的层，等于没做。

在进入 L1 之前，还有一件成本最低、收益最高的事。

我希望把日常对话、QPC 知识库与日历逐步放进一个个人助理，同时控制小型 VPS 的资源占用。已有 Hermes 网关正在使用另一只 Lark 机器人。这个实验的目标是暂停 Hermes，在同一台共享小机上尝试运行 OpenCode，并使用 personal-assistant 的机器人验证接管链路。

**同日补充：**第一次窗口结束前的消息被中断；经再次授权，重开受保护的短时窗口后，真实 Lark 两轮私聊均收到回复，第二轮正确使用了前文。模型任务期间的内存峰值和压力依然偏高，尚不能据此判断适合在这台小机上长期常驻。

这次实验的边界很窄：测试短时对话、资源和回退；QPC 与日历不是这次已经实现的能力。两只机器人独立，暂停 Hermes 会暂时影响原机器人，不会自动把它的会话和权限迁移到新机器人。

为什么不能只比较一个 RSS

在决定切换前，观察到 Hermes 主进程的一次 RSS 约 341 MiB，另有进程数据进入 swap。本机 WSL 中 OpenCode 空闲服务的主进程 RSS 大约 224–262 MiB。但 Hermes 当时正在承担实际网关工作，OpenCode 的本机测试没有接真实 Lark 或模型。不同机器、不同负载和不同统计口径不能直接得出完整替代方案的节省量。

共享实例约有 952 MiB 可见内存，Hermes 运行时多次采样的可用内存只有一百多 MiB，还有明显 swap 使用。相比直接叠加一个服务，先暂停旧网关、在相同机器上测量完整链路，更接近实际问题。

把切换做成可回退试验

方案是由已有的轻量 Lark 入口负责本人身份检查、消息去重与回复状态，OpenCode 仅在本机回环地址提供模型对话接口。服务使用非特权用户、单独工作目录、内存和 CPU 限额；OpenCode 工具权限默认拒绝，试验不开放文件修改、Shell 或其他外部动作。模型凭证和机器人凭证分开提供，不放入仓库或文章。

切换前设置了十分钟自动回退，并持续观察内存余量、内存压力和关键服务状态。试验失败或达到时限时，停止试验服务，恢复 Hermes gateway 和 A2A bridge。两个服务独立恢复，是因为 bridge 没有声明会自动跟随 gateway 的依赖关系。

对话适配器每轮创建独立 OpenCode 会话，只加入已确认送达的有限历史；调用超时不自动重试。模型回答和 Lark 成功投递分开记录。OpenCode 自身会在状态目录写入会话数据，尝试调用 API 删除会话并不等于证明底层数据被彻底擦除，因此试验使用独立目录并在结束后清理。

调研时间：2026 年 10 月 30 日。本文中的 Grok Bot 指 xAI 官方产品，不是 X 上的 @Grok 机器人。结论来自官方产品说明和文档，未独立实测其可靠性、费用或效果；产品和价格可能变化。

一个个人助理最难的地方，往往不是再接一个更强的模型，而是让人知道：它是否记得上文，是否真的查到了资料，动作有没有完成，以及中断后该怎么办。Grok Bot 把这些问题摆在了产品设计中心。它的答案有值得借鉴的地方，也有不适合照搬到我们项目的地方。

它到底是什么

官方介绍把 Grok Bot 描述为可持续工作的 AI 队友：通过对话接收任务，在云端计算机里使用浏览器、文件和终端，与外部应用交互，遇到需要授权的动作时请求用户处理。当前概览列出桌面和移动客户端，并称后台任务可以在客户端关闭后继续。它强调的不只是给出建议，而是尽量让工作发生在实际工具中。

有两个容易误解的细节。第一，多个 Bot 的独立身份不等于每个 Bot 一台隔离计算机：FAQ称同一账户的 Bot 共享一台云端计算机及其文件、浏览器会话和登录状态，因此不能把不同 Bot 当成安全隔离边界。第二，云端计算机与用户眼前的 Windows 电脑是两种不同的执行环境；本地命令执行另有授权设置。它的服务和计划条件会变化，应以当前文档为准。

启示一：连续性要分层，而不是把聊天一直拼长

设计文章将 Bot、聊天、提示、工具和成果作为主要产品对象；Bot 文档描述了偏好、长期事实和工作记录与聊天历史的区别。官方还说明 Bot 会自行决定保存部分记忆，个人 Bot 的记忆通过对话查看、纠正或删除，重置会话不会同时删除记忆。

我们的场景需要更克制的分层。当前代码保留进程内最多 12 轮、48000 UTF-8 字节的已送达对话；重启清空，淘汰时提示前文缺失。真实 Lark 长对话及资源消耗尚待验收。QPC 多维表格是用户明确整理的长期知识来源，Lark 日历是日程来源；不能把所有对话自动变成 QPC 事实，也不必为了模仿 Grok Bot 立刻实现长期自动记忆。

下一步可以先做一组可重复的长对话验收：在第一轮给出合成约束，跨多轮追问并观察约束是否仍在；再故意超过窗口，确认提示出现、模型不编造。记录调用量与实际延迟，而不是把窗口大小等同于理解能力。

启示二：从“回答”到“可核验的结果”

Grok Bot 的产品主张是工作落在真实应用中。对我们的单用户 Lark 助理，这意味着一次“查知识库”应能指出具体记录，而不是让模型凭印象回答。当前 QPC 只读检索已在代码中实现：明确输入关键词，分页查配置中的表，返回匹配片段及记录 ID；部分扫描失败不会说“没有结果”。它尚未完成真实权限与私聊链路验收。

这条路径比先做通用工具平台更适合现在：先验证本人身份、表访问权限、分页、超时和输出；再根据真实需求决定是否支持自然语言路由。若以后要写入 QPC 或日历，至少要记录目标、参数和外部系统返回的可核验结果。返回成功、明确失败和结果不明应分开：网络超时可能发生在对方已处理之后，不能自动重复创建。

调研时间：2026 年 10 月。本文依据 Manus 官方公开材料和本项目现状分析，并非独立测评；产品和订阅规则可能变化。

向一个聊天机器人提问，通常得到一段文字；向一个任务型 agent 提问，我们期待的是一份可以使用、检查、继续修改的成果。Manus 对后者的探索，值得我们研究。但我们要建设的是单用户、Lark 优先、资源节制的个人助理，不必把云端通用工作平台的整套基础设施搬回本机。

Manus 做了什么：把回答变成工作过程

Manus 将任务组织为模型决策与工具执行的循环。其工程文章描述：收到请求后，模型从已有动作空间中选择工具，运行工具得到观察，再把动作和观察加入上下文，直到任务结束。这是厂商对其工程设计的描述，并不意味着每次执行都正确。来源：Context Engineering for AI Agents

官方介绍称，每项任务可获得隔离的云端虚拟机，有文件系统、网络、浏览器和工具。隔离环境可以让 agent 做调研、操作文件、编写和执行代码；它仍需要对外部服务的权限和审计，不能因为称作“沙箱”就假设任何联网动作都安全。来源：Manus Sandbox

此外，Manus 提供本地浏览器和本地计算机接入方式。Browser Operator 文档描述单次授权、任务标签页、人工介入和停止；My Computer 文档描述本地文件夹授权与命令执行许可。这些是特定产品功能的授权机制，不可推导为所有动作都自动安全。浏览器操作 · 本地计算机

对我们最有价值的不是“加一个浏览器”，而是从结果倒推每一步应该留下什么证据：用户要求查询知识库，最终应能看到来源；要求登记日程，应能看到实际创建的事件；遇到超时，应明确“结果未知”，而不是让模型把计划中的动作当作已完成。

上下文工程：保留可以找回的线索

Manus 在工程文章中提到，长上下文会增加成本，过度压缩也会损失信息；它使用文件系统存放可按需重新读取的信息，并尽量保留 URL、文件路径等可恢复线索。文章也讨论稳定前缀与缓存、保留错误以便恢复，以及通过约束动作选择而不是随意删除工具定义来控制工具集。这些是其公开经验；缓存是否可用、是否节省费用，仍取决于具体模型服务。来源

我们的边界不同：当前上下文是进程内最多 12 轮、48,000 UTF-8 字节，按完整轮次淘汰；前文被淘汰后会提示，重启清空。它解决了短期衔接，不能保证任意长对话都不遗忘；真实 Lark 长对话与资源消耗尚待验收。

因此，下一步不必先做一个“自动永久记忆”系统。可以围绕真实对话，区分三类信息：

1. 近期对话：用于连续回答，有明确容量上限和截断提示。
2. 知识来源：用户明确让助理查询或记录的知识，来源放在已有 QPC 多维表格；长期内容不是聊天摘要。
3. 外部状态：日程、知识记录等以 Lark 实际结果为准，保留对应记录标识，而不是以模型自述为准。

例如用户问“继续刚才讨论的方案”，如果关键事实已被淘汰且没有可引用的知识记录，助理应该说缺少依据，请用户补充；只有明确请求查询时，才从获准的 QPC 表中检索相关记录。当前 QPC 只读检索已在开发分支实现，但真实权限、字段和端到端收发仍待验证；写入、修改和删除尚未实现。

从演示走向可靠闭环

Manus 对自动化的介绍强调，可以定义触发条件、数据来源、测试运行、确认方式和失败后的查看与暂停。来源：Automations。这启发我们：功能是否可靠，不在于是否能展示一次成功，而在于它能否处理重复输入和不确定结果。

以“帮我记一条 QPC 知识”为例，一条未来可实现的最小流程应该是：

• 用户明确要求记录，助理检查已有表结构与允许的字段；不改表头，不把所有聊天自动存入知识库。
• 程序校验内容与权限，发送一次写入请求；只有获得可验证的记录标识后，才报告保存成功。
• 接口超时后，不能简单重试或声称失败；先查证是否已经创建，无法查证时明确报告结果未知。
• 重复消息、进程重启和发送结果不明都要有独立测试，保证恢复流程不会绕过授权。

这是设计提议，并非本项目已有能力。第一步仍应先完成 QPC 只读检索的真实验收；之后再根据实际需要选择写入或日历查询。

并行与成本：有用，但不必提前拥有

Manus 的 Wide Research 面向需要对大量独立对象逐项调研的任务；其公开介绍描述主任务拆解、独立子任务并行执行以及结果汇总。来源。文中的质量提升是厂商对架构的论述，不应当直接当成对所有问题有效的独立基准结论。

在资源受限的环境（例如 512MB 内存、1 个共享 vCPU 的 VPS）中部署 AI 智能体，最大的挑战不是模型推理能力，而是常驻进程的内存占用与不可控的运行开销。

本文分享一套极简智能体方案，核心设计目标是：空闲时接近零开销，按需拉起重组件。

一、 核心设计原则

1. 架构：单一常驻进程 + 按需子进程。
2. 推理：本地不跑模型，所有推理走远程 API。
3. 存储：大部分数据存储在 SQLite 和普通文件中，不依赖复杂的中间件。
4. 按需拉起：重型任务（如浏览器自动化）运行时加载，任务结束立即释放。

二、 架构实现方案

1. 网关与路由

• 网关：采用 Telegram 等单一渠道，利用 httpx 实现长轮询，不引入庞大的 bot 框架，不开 Webhook 服务端口。
• 零 AI 路由：在进入 LLM 之前，先进行命令前缀和规则匹配。命中确定性技能则直接执行，不调用 LLM。这层路由通常能过滤大部分低价值请求，节省 API Token 和运行资源。

2. 调度与状态机

• 状态机：手写简单的 asyncio 状态机（约 150 行），限制最多 3 到 4 步。通过结构化的 action_type（tool_call, clarify, cannot_proceed, done）解决智能体"只计划不执行"的问题。
• 调度：弃用复杂的 APScheduler，使用 SQLite 任务表结合一个"睡到下一个到期任务"的协程进行调度。若要求极致，可利用 systemd timer 在需要时唤醒进程。

3. 记忆与工具管理

• 记忆：核心数据采用 SQLite + FTS5 全文检索，避免部署笨重的向量数据库。夜间通过远程任务进行压缩和去重。仅在确实需要语义检索时，配合远程 embedding 和 sqlite-vec 按需启用。
• 工具：实施风险分级注册表。高风险动作需走 pending_confirmation 闸门。MCP 服务以 stdio 子进程方式懒启动，用完即退。浏览器自动化是最大内存开销项，强制单实例，任务结束立即 Kill。

4. 安全与可观测性

• 安全：凭证与 Agent 核心进程分离，由工具层独立持有，Agent 仅发起请求。
• 可观测性：使用 SQLite 表记录日志并配合日志轮转，不本地部署 Langfuse，需要可视化时利用云端免费版。

三、 资源预算表（估算）

硬限制方案：写入 systemd 配置（MemoryMax=400M, CPUQuota, TasksMax），并配少量 zram。超限时由 systemd 杀掉子进程，确保主进程稳健。

mem0 最小部署：193MB 跑起来的 Agent 记忆层，瓶颈却不在内存

mem0 是这两年的 Agent 记忆层网红。但当你真的想把它塞进一个个人项目时，第一个问题不是"怎么用"，而是"它到底要吃多少资源"。

上个月的结论是「票息探至 1.68%，短端极度平坦」。一个月过去，这两句话都需要改写。

Anthropic 的看板不在看板里

这是《给本地 Agent 造一块看板》系列的番外。系列正文用同一套七层能力框架（C1–C7）解剖了 20 个开源看板与编排项目，本篇回到一个更上游的问题：如果这个场景真有标准答案，行业里最有钱、最懂 agent 的那家公司是怎么做的？

三条先行结论

1. 事是真的，形态是假的。 Anthropic 确实有一套让人和 agent 一起接活、认领、交付、复核的机制，而且已经在全员规模上跑了大半年。但公开材料里没有任何一处把这件事描述成看板。

2. 最像看板的那套东西，是用文件实现的。 它的共享任务列表、消息邮箱、并发防冲突，全部落在本机文件系统上——~/.claude/tasks/ 加一堆 JSON 文件加文件锁。跟我在系列第二篇里拆的 kanban-md 几乎是同构的。

3. 它主动放弃了无人值守。 这是最反直觉的一点，也是最值得带走的一点：Anthropic 做了自动领取（self-claim）、做了原子防冲突（file lock）、做了依赖自动解除，然后在最关键的入口上写下一句「非交互模式下不会创建 teammate」。它把「人」当成设计的一部分，而不是需要消除的瓶颈。

先澄清：这条说法可能混了三个东西

搜下来，容易被并成一个「Anthropic 内部看板」的，实际是三套不同层面的东西：

此外还有第四件：Anthropic 把自己内部「有多少活是 AI 干的」做成了公开指标，2026-09-17 发布。它不算看板，但它提供了理解前三个的坐标系。

我的核实原则和系列一致：一手优先，二手标注，推测剔除。下面每一条事实都给出出处，末尾附证据分级。

第一套：Claude Tag —— 把 agent 放进通讯录，而不是放进看板

Claude Tag 的官方描述里有一句很关键的话：

给本地 Agent 造一块看板（一）：总览——看板只是壳，调度与验收才是本体

本系列共八篇，用同一套评价框架横向解剖 20 个开源任务看板 / 编排项目。 所有仓库元数据（星数、许可证、最近提交时间、仓库体量、创建时间）均于 2026-10-08 通过 GitHub REST API 一手核验，不采信二手索引站与聚合博客。 本系列刻意区分「架构设计」与「工程成熟度」，对明星项目同样保留独立判断。

一、场景：一句话的需求，七层的实现难度

先把需求写清楚：

人在一块看板上发布任务 → 本机的多个 coding agent（CodeBuddy / Codex / Trae / CodeArts 之类）定时扫描看板 → 自动领取并完成 → 持续产出可复用的资料或信息 → 由此把各家的免费额度用满。

这个描述里最容易被抓住的关键词是看板。于是绝大多数调研都会从「找一个开源看板」开始——我第一轮也是这么做的，然后发现结论很别扭：看起来功能最全的几个项目，恰恰都不能自主干活；而真能自主干活的，看板又都很简陋。

问题出在提问方式。看板只是这套系统里最外面的一层壳。 把需求拆开会发现，真正决定"能不能无人值守长跑"的，是底下那几层：

这张分层图是本系列的评价基准。后面每篇都会用同一把尺子去量不同项目。

给本地 Agent 造一块看板（二）：文件系统派——把看板塞进 Git 仓库，代价是什么？

本系列共八篇，用同一套七层能力框架（C1–C7）横向解剖开源任务看板。 本篇覆盖 antopolskiy/kanban-md、MrLesk/Backlog.md、JRGould/Kanbanito、Patrik-Stas/mdboard。 元数据于 2026-10-08 经 GitHub API 一手核验。

一、这一派的共同信念

文件系统派的出发点是一个很朴素的想法：既然 agent 已经能读写文件，那看板为什么不是一堆文件？

于是它们把看板的三个元素直接映射到文件系统：

这个映射带来的好处是立竿见影的，而且几乎全是"agent 视角"的好处：

• agent 零成本可读。 不需要 API、不需要 SDK、不需要鉴权，一个 Read 就能拿到任务全文。凡是能让 agent 直接读文件的地方，上下文成本就比走 HTTP + JSON 低一档。
• 可 grep、可 diff、可 review。 任务变更走 git，天然有历史、有 blame、能回滚。
• 可分支、可合并。 多人（或多 worktree）可以各自在分支上改任务，再合并回来。
• 无守护进程、无数据库、无端口。 它不需要"起来"，它本来就在那儿。

但也正是这个映射，埋下了这一派最大的结构性缺陷。先把四个项目摆出来，再回来说这个缺陷。