为了防备儿子们突然问起一个我不懂的科学问题，我花了一年多时间，陆续给他们写了十几本科学知识系列丛书，目标是减少我回答“不知道”的次数，并且能够更系统性地去做科学知识的灌溉。这套书是以一个小男孩的视角，讲述他与一个2055 年的 AI 助理“轨道”一起探索不同科学领域知识的故事。

孩子们特别喜欢“轨道”这个反重力半透明蓝色光球，因为他知道所有的知识，同时还很幽默，而且似乎在它的背后有一股神秘的力量在操纵。写书的过程中，我一直想给这套书配一个跟“轨道”同名的问答助手。孩子读完故事后，可以继续追问其中的科学概念。以后碰到相关问题，助手又能把新的疑问与此前讲过的内容接起来。这样一来，书中那个陪着他们探索的 AI 角色，就能从故事延伸到日常学习中。

— 图 1：“轨道”的交付首页只保留科学知识助手与提问入口

然而，这个想法在我的写作计划里放了很久，始终停留在设想阶段。一个能够长期使用的随书助手，要把书里的知识和角色组织起来，让每次问答可以保存并积累，最后交付一个孩子随时能打开的入口。每个环节都有成熟做法，但把它们组合成一套可以长期维护的系统，就会变成一项完整工程。由于书稿本身已经占用了主要精力，这条支线便长期搁置在待办列表。

读完 Yaohui 关于 DeepSeek Harness 系列文章后，我决定用它来试试。《用 DeepSeek Harness 开发一个运行在 DeepSeek Harness 上的云服务器管理 Agent》已经跑通了一条链路：先在 DSH 中做好一个领域 Preset，再由同一套 DSH 加载和运行。Preset 可以理解为一套封装好的 Agent 配置，里面写着它要扮演什么角色、遵守什么规则、可以使用哪些工具。到了《DeepSeek Harness 的野心：统一领域 Agent 的构建、运行和交付》，这条链路被概括为构建层、运行治理层和产品交互层。服务器管理 Agent 已经证明前两层可以工作，所以我想看看产品交互层能否把 DSH 的技术控制收进页面背后，让孩子打开浏览器就开始提问。

结果比我原先设想的快得多。第一版 Preset 很快进入试用，测试回答以后调整难度和篇幅，接入书籍材料以后收紧调用条件，随后建立用户专属运行实例，精简界面，并发布到固定网址。孩子们看到页面时非常惊喜。他们平时经常用通用 Chatbot 询问科学知识，如今身边多了一个专门为自己制作的助手。它连接着读过的科普丛书，按照我设定的信源规则回答问题，而且能够把学过的内容保存下来，供以后关联和复习。

若按常规路线推进，我首先要写一个 Agent 服务，把模型、Prompt 和书籍检索串在一起。Demo 搭起来以后，就要开始补上长期使用所需的记录保存和聊天页面，最后处理访问接入。由于开发发生在代码环境，测试发生在另一个运行入口，每次修正都伴随着日志搬运、配置同步和重新发布。

这些工作都有成熟方案，但是隐性的长期维护成本高昂，尤其是我在这方面的技术经验并不算太充分。我的目标是让这个助手长期陪伴孩子积累知识。第一篇《从“Everything is a Plugin”看 DeepSeek Harness 的设计》曾经提出一个评价尺度：领域团队能否借助 DSH，比从零搭建更快地做出可以持续运行和检查的 Agent。服务器管理 Preset 已经给了我一个答案，因为 DSH 已经提供了会话运行和 Web 入口，工具、权限与日志又在同一套事件系统中工作，我可以把精力放在领域规则与使用体验上。

因此，这次开发的速度主要来自 DSH 已经提供的运行能力，Prompt 生成只占其中很小的一部分。从需求梳理到发布，所有修改都能回到 DSH 中完成，开发过程中始终看得到 Agent 怎样运行，以及下一次应该修改哪一部分。这个 Harness 的意义在于：业务逻辑以外的工程约束相对稳定清晰，且同时兼顾了开发和运行的环境。

我最先交给 DSH 的，是一份简短的面向十岁左右儿童的科学助手开发需求。它要用权威资料回答天文、物理和生物等问题，开头先给出结论，随后解释必要的分类、原理和例子。语言可以降低阅读负担，科学概念却要保持严肃性和完整性。每次问答产生的新知识还要写入工作区，方便后续问题重新调用。

在创建 Preset 以前，DSH 围绕几个会影响实现的问题做了需求梳理，例如资料来源怎样排序，知识只保留在当前会话还是写成结构化卡片，现有文件工具能否满足需求，以及安全边界要放在哪里。确认这些问题以后，角色设定、可用工具和知识管理规则被装进同一个 Preset。第一轮交流结束时，我已经能够在 DSH 中新建“轨道”会话并开始测试。

第三篇《通过一次完整操作理解 DeepSeek Harness 的设计》区分过 Preset 和整套运行配置：前者规定具体会话怎样工作，后者规定整个服务怎样启动。这个分工让第一阶段很聚焦。我先处理“轨道”怎样回答、能够读取哪些资料、问答怎样留下记录，等这些行为稳定以后，再建立用户专属入口并处理远程发布。

十几分钟后第一版的 Preset 就完全可用了，他也很快暴露出需要修正的地方。我用太阳系问题做测试时，回答篇幅偏短，措辞过于低龄，天体分类的覆盖范围偏窄。于是，我把读者重新描述为“求知欲较强的十一岁左右儿童”，要求回答保留必要的术语和完整分类，并通过清楚的解释降低理解难度，同时让语气保持正常、平实。

这次修正显示了运行记录在开发过程中的作用。开发会话读取试用记录，就能看到孩子问了什么、模型怎样回答、期间调用过哪些工具，然后修改同一份回答规则。第二篇《从插件树到 Session Log：DeepSeek Harness 的复杂概念怎样连成一套系统》把这种运行记录视为系统实际发生过的事实，第五篇验证过“从运行记录发现问题并回到创造会话修改”的维护方式。在“轨道”里，这条反馈路径很短。我指出回答的问题，开发会话找到对应记录并修改规则，新会话随即使用更新后的 Preset。

回答方式稳定以后，我开始把书中的角色和知识接进孩子正在使用的“轨道”。

我先向 DSH 说明了两种“轨道”的关系。书中的角色生活在未来世界，当前助手服务于现在的孩子。它可以沿用角色的表达方式，理解人物关系，并把书中的经历作为故事讲述，但身份和时间边界要保持清楚。随后，书籍正文、人物资料和连续性记录被整理进同一个工作区，Preset 规定这些材料何时调用、引用时怎样标明书名，以及公共科学资料怎样补充书中的叙事表达。

经过这一步，角色延续便有了材料基础。角色设定管理身份和语气，文件工具负责定位原文，知识管理规则把书籍出处写进知识卡。书中积累的内容由此成为 Agent 可以调用的资料，科学结论继续受信源规则约束。

最初的调用规则比较粗，每个问题都会先扫描书库，响应速度因此受到影响。几次使用以后，书籍应该怎样参与回答已经很清楚。孩子明确提到书名、人物或故事时，Agent 会定位相应材料。问题与书中某个主题有清楚关联时，它只读取命中的一小段内容。普通科学问题则沿公共知识路径回答。经过调整，书库成为有条件触发的专属来源。

对于这个 AI 助手回答问题的能力而言，这个阶段结束后其实就已经基本结束了，加上所有的资料准备和调试时间，一共花了不到 2 小时。

Preset 稳定以后，问题从“轨道怎样回答”转向“孩子怎样使用”。我希望孩子每次打开页面都进入固定的工作区和 Preset，日常提问拥有合适的文件权限，并且与主 DSH 的设置和会话分开保存。

为此，我打包了一套用户专属 Profile。Profile 可以理解为一套进程级运行配置，用来固定模型、权限、工作区和默认 Preset。随后，我用独立数据目录启动一个新的 DSH 进程。这个目录保存专属入口的设置和会话，新进程提供单独的网页服务。第二篇梳理过这类配置怎样被 DSH 加载，这一次，它成为一套可以单独启动和维护的产品配置。

主 DSH 保留完整的开发和调试能力，用来修改 Preset、检查文件和查看运行记录。用户专属进程默认加载“轨道”，会话历史保存在自己的数据目录中，文件权限限制在规定工作区。这样既保留了开发能力，孩子的使用记录又拥有独立空间。

独立运行以后，孩子看到的仍是完整 DSH 页面，上面保留着模型、工作区和运行记录等构建者工具。这些入口增加了理解负担和误操作空间，因此用户专属页面只需保留对话与会话历史，原来的 DSH 进程就天然成为了“轨道”的管理平台。

界面调整分成两个动作。我先从用户专属运行配置中移除模型和插件管理等构建者工具，只保留网页运行与远程访问所需的加载项。随后增加一个很小的界面加载项，用它隐藏剩余的管理入口，并把侧栏、首页文案和网站标识改成“轨道”的蓝色半透明小球样式。

第四篇《DeepSeek Harness 源码解读：插件运行时、Agent Loop 与 Session Event》分析过，DSH 的 Web 界面本身也由插件组合而成。因此，“轨道”可以继续使用原有页面，只在用户专属入口中隐藏或替换一部分内容，主环境的源码和界面保持原样。

孩子打开页面时，看到的是“轨道”、科学知识助手、输入框和会话历史，提问从这里就可以开始。模型与 Preset 已经固定，工作区和权限在后台生效，运行记录留给构建者检查。同一套 DSH 在主环境里保留完整的开发界面，在用户专属入口中只呈现一个科学助手。

— 图 2：普通科学问题沿公共科学路径回答，运行配置与资料规则已经由构建者预先固定

用户专属进程在本地运行以后，最后一步是把它交付到孩子能够访问的网址。我沿用了主实例已经使用的 Full Remote 插件，让它处理远程访问和登录，再用 Cloudflare Tunnel 把固定网址的请求转到这个用户专属页面。

发布完成以后，外部访问进入前面建立的用户专属运行实例，Agent 的行为继续来自同一份 Preset。此后，Preset 管理回答规则，Profile 管理运行方式，界面加载项管理页面显示。开发、运行和远程访问由此连在同一套系统中。

第六篇曾经提出，DSH 的公共系统之上可以形成面向具体领域的产品交互层。到这里，这个判断终于有了孩子能够打开的页面。DSH 继续负责构建和管理，用户专属入口只呈现科学问答。

至此，整个 Agent 的第一个可交付版本就已经全部搭建完成了。

— 图 3：从需求澄清到固定网址，构建、试用、资料接入和交付都沿同一套 DSH 逐层完成

问题进入“轨道”以后，它会先读取知识索引，查看相关主题是否已经形成卡片。关联足够清楚时，回答会接回此前学过的概念，关联较弱的问题则从当前疑问开始。接下来进入来源判断。稳定的基础知识按照科学规则组织，需要核对时查询权威公共资料，书籍、人物或故事达到调用条件时，文件工具才会定位相应片段。

资料准备完成后，回答协议开始控制难度和篇幅。开头先给核心结论，正文随后解释关键术语、分类、机制和例子，结尾提供一两个可以继续探索的方向。面向儿童改变的是解释顺序和语言负担，知识结构与科学边界保持完整。

回答结束以后，固定知识工具会保存新内容。它把本次问题的核心要点、来源和学科关系写入知识卡，并同步更新索引与知识地图。书库连接孩子过去读过的内容，知识卡记录今天新学到的内容，知识地图则让后续复习可以沿着主题关系展开。孩子新建会话以后，这些积累依旧保存在工作区里，家长或构建者可以检查和修正。

随着知识逐渐积累，我准备补上不合理内容拦截功能。目前 Preset 已经预留了这项功能，具体拦截规则仍在开发。此外，知识卡片的落地可以让系统未来周期生成学习报表，分析孩子的知识掌握情况，并提示适合复习的内容。DSH 目前似乎还缺乏周期任务的机制，这块可能需要写个插件来实现。

— 图 4：一次提问经过知识索引、来源判断和回答协议，最终写回知识卡、索引与知识地图

两张截图正好表现了来源分支。普通生物问题沿公共科学路径生成回答。当天文问题与书中内容形成明确关联时，“轨道”会读取相应材料，在孩子熟悉的表达上补充科学说明和来源。书库只在关联达到调用条件时参与回答。

— 图 5：天文问题命中既有丛书内容后，“轨道”读取相关材料，并明确列出书籍来源

孩子们已经习惯向豆包询问科学知识。豆包提供的是覆盖面很广的通用问答，“轨道”建立在他们读过的科普丛书之上。它熟悉书中的角色和表达，科学资料遵循设定的信源规则，问过的问题会进入自己的知识体系。以后遇到相邻概念，新的问题便有机会接上过去的阅读和问答。

他们第一次看到“轨道”页面时的惊喜，让我意识到这种专属感来自多层联系。名字和形象带来熟悉感，书籍材料连接过去的阅读，权威来源托住回答质量，知识卡和知识地图又把今天的问题留给未来复习。通用聊天工具帮助他们进入更广阔的知识世界，而这个助手把阅读、问答和长期积累组织成了一条属于他们的学习路径。

我之所以把它称为 Agent，正是因为工作会越过当次回答继续运行。Prompt 负责表达，Preset 组织角色、工具和规则。问题结束以后，知识工具更新跨会话状态，运行记录为后续修正提供依据。孩子看到一个对话框，后台持续保存知识和运行记录，并为下一轮问题准备上下文。

同样的目标可以用常规 Agent 框架和 Web 技术完成，只是工程通常会分散到多个项目里。开发者要分别维护 Agent 服务、书籍资料和用户页面，还要自己处理会话保存与远程访问。每一部分都有自己的配置与日志，Prompt、工具定义和线上版本也要保持一致。

更麻烦的是，后续修正会沿着这套分散结构不断往返。例如一次回答偏短，开发者要先定位线上会话，再回到代码侧修改 Prompt，随后同步配置并重新发布。知识漏写或书籍引用出现偏差时，又要进入另外几套日志和存储中排查。问题本身可能很小，修正过程却需要跨越多个系统。

在 DSH 中，开发会话可以读取用户会话的运行记录，并修改同一份 Preset，书籍和知识文件也留在同一个工作区。用户专属运行实例和界面都由 DSH 加载，测试上下文无需在多个平台之间搬运。

— 图 6：常规技术栈与 DSH 都能完成目标，但 Agent 行为、运行配置与反馈路径的组织方式不同

“轨道”之所以能够很快从设想进入试用，原因正落在这条反馈路径上。我刚把需求讲清楚，Preset 就可以接受第一轮测试。回答暴露问题以后，开发会话通过运行记录找到对应内容并修改。行为稳定以后，同一条工作流继续完成资料接入、用户实例建立、界面调整和远程发布。每次修改都能沿着运行记录回到明确的工程环节，所以这个版本才会持续快速收敛。

第一篇讨论 DSH 的复杂时，它的判断是，它把更多控制权交给构建者，因此构建者承担更多产品设计责任。第六篇在此基础上，将这套控制能力分成构建层、运行治理层和产品交互层，并提出领域 Agent 可以在同一个公共系统中完成构建、运行和交付。

在“轨道”中，构建层由 Preset 主导，它把角色设定、知识工具和书籍资料组织成可以运行的 Agent。运行治理层由 Profile 和用户专属进程承担，用来固定模型与权限，分开保存会话，并提供远程访问。产品交互层就是经过精简的页面，孩子看到的是专属科学助手，主环境继续保留开发与检查能力。

— 图 7：“轨道”把 Preset、Profile 与专属网页分别落在构建层、运行治理层和产品交互层

“轨道”是第六篇所说的统一方式在家庭场景中的一次实现。公共系统管理模型与工具，并保存权限状态和运行记录。具体 Agent 则按照用户的任务组织资料、能力边界和界面。服务器管理 Agent 面向运维操作，“轨道”面向孩子的科学问题。两者使用同一套 DSH，却可以呈现完全不同的使用方式。

随书问答助手曾经长期留在计划表里，DSH 让它变成了一条可以逐层完成的开发路径：先定义 Agent 的行为，再组织资料和运行环境，最后处理界面与远程交付。第一版已经运行，孩子已经开始使用，书籍、权威资料和长期知识体系终于有了同一个入口。对于我写给孩子的这套科普丛书来说，这个助手让故事中的陪伴继续延伸到了书外，并且能够随着他们不断提问，逐渐积累出一套属于自己的科学知识体系。