调研时间：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 杀掉子进程，确保主进程稳健。

在 AI Agent 的落地场景中，随着 Agent 承载的业务逻辑日益复杂，如何确保其行为的可审计性成为了企业级应用的关键。一个常见的误区是试图通过让模型“自我解释”或直接在工具逻辑中添加追踪标记来审计。

本篇博客探讨如何通过架构解耦，构建一个轻量、防篡改且不干扰模型执行的 Agent 审计框架。

1. 为什么审计逻辑不能内置于工具？

在早期的设计尝试中，我们曾考虑在每个工具（Tool）函数内部添加日志记录逻辑。但很快发现这种做法存在以下问题：

• 代码耦合度高：工具本身的职责是执行任务，审计职责的增加会破坏单一职责原则。
• 一致性难以维护：随着工具库的扩展，审计逻辑的碎片化会导致不同工具的日志格式不统一。
• 难以防御篡改：如果审计逻辑由被审计对象（工具/模型）直接维护，恶意调用可能会通过覆盖日志来掩盖踪迹。

2. 审计框架的核心设计原则

我们建议将审计框架与执行逻辑物理分离，采用 “Dispatcher 拦截模式”：

• 执行与审计物理隔离：所有的审计信息由底层的 Dispatcher（调度器）负责记录，而不由 LLM 直接参与生成或维护。这从根源上消除了模型幻觉干扰审计日志的可能。
• 上下文无感注入：在请求到达系统的一瞬间，框架为该行为链分配唯一的 TraceID。在调用工具前，Dispatcher 负责将 TraceID 像“补丁”一样注入调用参数。
• 结构化元数据存储：不要将审计标记嵌入 Markdown 或模型输出的正文，而是将其作为元数据（Metadata）存储在结构化数据库中。

3. 如何防范 LLM 幻觉干扰？

对于“模型是否会伪造审计标记”的担忧，我们采用以下验证机制：

1. 确定性分配：由框架代码负责 ID 生成，LLM 仅作为无状态的执行引擎，对 TraceID 的生成过程不可见、不可控。
2. 不可逆日志哈希链：在审计日志写入时，引入哈希链（Hash Chain）。每一条行为日志的 Hash 都包含上一条日志的 Hash。由于 LLM 无法预测后续 Hash 值，它在事后即便试图篡改记录也无法通过校验。

4. 未来展望

Agent 的透明度不是为了限制它的行为，而是为了让开发者在复杂多变的 AI 应用场景中，始终能保持“可控感”。通过将审计层下沉到架构底层，我们将能把更多的资源投入到更高级的决策优化中。

本文基于对 Agent 行为审计框架的实战总结。

这是一组关于 DeepSeek Harness（简称 DSH）的源码级解读。第一篇先回答一个很现实的问题：市场上已经有 Codex、Claude Code，为什么还需要 DSH？

先说结论

如果需求是“给我一个现在就能写代码的 Agent”，普通用户没有太多理由选择 DSH。Codex 和 Claude Code 的优势在于完整的产品体验：安装、权限、上下文、编辑、测试、恢复和日常交互都已经被包装好了。

DSH 的合理定位不是“另一个更好用的 Codex”，而是：

一个可编程、可替换、可嵌入、可自托管的 Agent Runtime，同时提供一个 DeepSeek 原生的 Coding Agent。

这两个定位看起来相近，实际上面对的是不同买家。

三种产品不是同一层

可以把 Agent 市场拆成三层：

模型层：DeepSeek / OpenAI / Anthropic / 自建模型
运行时层：DSH / OpenAI Agents SDK / Google ADK / LangGraph / Pi
产品层：Codex / Claude Code / 企业内部 Agent 产品

Codex 和 Claude Code 的核心目标是让用户完成任务。它们当然也在开放 Skills、MCP、SDK 和企业部署能力，但用户不需要先理解运行时内部结构，就可以开始工作。Codex 开发者主页、Claude Code CLI 文档

DSH 的重点则是把运行时本身暴露出来：模型适配器、工具注册表、Session Log、Agent Loop、沙箱和审批都可以通过插件和配置组合。官方架构文档甚至明确写道，产品中的这些部分都属于插件，而不是一个必须修改的特权核心。DSH 架构文档

从 luck-agent 到 Hermes-lite，我花了两年时间才想清楚这个问题：80% 的请求不需要"思考"，只需要"路由"。

回顾：ReAct 控制器模式的困境

2024 年做 luck-agent 的时候，我采用的是经典的 ReAct 模式（Reasoning + Acting）：

用户输入 → 大模型推理（意图识别 → 规划 → 工具选择 → 执行）→ 输出

所有请求，不管简单还是复杂，都走同一个推理链。一个"查 QPC 里有没有 VPS 相关的记录"的请求，也要经过：

1. 理解自然语言
2. 判断意图类别
3. 选择工具（search_qpc）
4. 构造查询参数
5. 执行并解释结果

问题很明显：

• Token 消耗大：每次推理要带上完整的 system prompt + 工具定义，光上下文就吃掉 3000-5000 token
• 延迟高：一个简单查询要等模型完成完整推理链，响应时间 3-8 秒
• 上下文窗口压力：随着工具数量增加（现在 Hermes-lite 有 20+ 个工具），system prompt 越来越大

我当时就在知识库里记了一条：

“对于个人助理场景，相比最初的 ReAct 控制器模式，Skill 技能路由更适合当前 luckagent：80% 请求是固定模式，不需要复杂推理，技能比 Agent 更稳定，成本更低，响应更快。”

Skill 路由的核心思想

一句话：预定义技能映射，轻量分类先路由，只加载需要的工具和 prompt。

用户输入 → 轻量路由（关键词/意图 → 技能）→ 加载专用 prompt + 工具 → 执行

路由表设计

# 简化版路由逻辑
ROUTING_RULES = {
    "qpc": {
        "keywords": ["QPC", "知识库", "记一下", "记录"],
        "skill": "qpc",
        "tools": ["feishu_bitable_read", "feishu_bitable_write"],
        "prompt": "qpc_skill_prompt"  # 只加载 QPC 相关的 prompt
    },
    "vps": {
        "keywords": ["VPS", "服务器", "防火墙", "Docker"],
        "skill": "gcp-vps-ops",
        "tools": ["terminal", "read_file"],
        "prompt": "vps_skill_prompt"
    },
    "blog": {
        "keywords": ["博客", "文章", "Hugo", "发布"],
        "skill": "hugo-blog",
        "tools": ["terminal", "read_file", "write_file"],
        "prompt": "blog_skill_prompt"
    }
}

对比：同样"查 QPC"操作

Hermes-lite 的 Skill 实现

Hermes-lite 的 skill 系统是这样工作的：

人类 chatbot 最尴尬的瞬间：第二次见面完全不认识你。Agent 的记忆系统怎么同时做到持久化、低成本、不丢上下文？我深入 Hermes-Lite 源码写了一个月，拆解出 5 层架构。

从「鱼的难题」开始

用过 ChatGPT 的人都知道一个痛：下次打开，它完全不记得你了。

对一次性聊天这没问题。但对个人助理——帮你管理 200 条知识库、追踪几个项目的进度、记住你的偏好——这等于每次都要把整段友情重来。

我做 QPC（个人知识库）时就被这个问题卡过。后来折腾 Hermes-Lite、nanobot，逐步摸到一条可行的路。这篇文章从 Hermes-Lite 的实际源码出发，拆解它的 5 层记忆架构，看看一个 Agent 是怎么解决「鱼的难题」的。

总览：5 层架构

┌─────────────────────────────────────────────┐
│  Layer 1: 持久记忆 (MEMORY.md / USER.md)     │  ← 跨会话，纯文本
├─────────────────────────────────────────────�
│  Layer 2: 会话压缩 (ContextCompressor)       │  ← 长对话不爆
├─────────────────────────────────────────────┤
│  Layer 3: 会话检索 (session_search + FTS5)   │  ← 历史不丢
├─────────────────────────────────────────────�
│  Layer 4: 增量写入门控 (Nudge 机制)           │  ← 该记就记
├─────────────────────────────────────────────�
│  Layer 5: 原子性保障 (fcntl + 临时文件)       │  ← 不丢不坏
└─────────────────────────────────────────────┘

每一层解决一个独立问题，层与层之间不耦合。下面逐层拆解。

主控制器是 Agent 的"大脑"——它决定何时思考、何时行动、何时停止。理解主控制器的设计，就理解了 Agent 的运作范式。

核心循环（Core Loop）

主控制器的本质是一个状态机：

接收输入 → 理解意图 → 选择工具 → 执行调用 → 处理结果 → 判断是否结束 → 输出/继续

这个循环的关键设计点：

1. 意图识别

不是简单的关键词匹配，而是结合上下文、历史、用户状态的综合判断。同一个"搜索一下"，在项目初期是搜技术方案，在部署阶段是搜报错日志。

2. 工具路由

主控制器维护一个工具注册表（Tool Registry），包含：

• 工具名 + 描述（供 LLM 选择）
• 参数 schema（JSON Schema）
• 权限等级（只读 / 可写 / 危险）
• 超时策略

路由逻辑：LLM 输出 tool_call → 控制器校验权限 → 注入上下文 → 执行 → 截断超长输出 → 返回结果。

3. 终止条件

这是最容易被忽略的环节。Agent 必须知道"够了"：

• 显式终止：用户说"停"或任务完成标记
• 隐式终止：连续 3 次工具调用返回相同/空结果
• 预算终止：token 消耗超过阈值，强制总结当前进展

生命周期管理

会话级生命周期

创建 → 活跃 → 空闲 → 重置 → 销毁

• 创建：加载用户上下文、历史摘要、可用工具列表
• 活跃：正常处理请求，维护对话历史
• 空闲：N 分钟无请求后，压缩历史为摘要
• 重置：用户显式 /new，清空当前会话但保留记忆
• 销毁：服务重启或长时间无活动

任务级生命周期

一个复杂任务可能跨多轮：