如何为知识工作构建智能体系统

目标是在你的智能体周围构建软件，为它们提供从事某类特定工作所需的上下文、工具和方法

@garrytan 是这样说的：

查看原推文

但人们真正想通过这个实现什么？你真的需要构建自己的 harness 吗？

如果你长期与智能体协作，无论是在某个项目上还是在某个特定领域，我认为你需要三样东西

1. 持久留存的知识与工作

你希望下一次会话能够带着上下文接着推进工作

例如，一个决策应当始终与其背后的证据和假设保持关联，并与建立在它之上的工作相连

你和你的智能体需要能够沿着这些关联追溯，并在情况变化时重新审视它们

2. 契合你工作方式的系统

例如，研究者需要追溯引用，并比较各种主张背后的证据

一家公司可能把客户历史放在 crm 里，把交付计划放在项目管理工具里，把财务假设放在电子表格里

向客户做出的一个承诺可能同时影响这三者，但它们往往存在于三个彼此分离的系统中

我想为这样一种做法辩护：用你和你的智能体基于自己的数据构建的自定义应用来取代它们，全部整合在同一个工作空间里

你希望塑造智能体处理你信息的方式，并让系统随着你实践的演进而不断进化

3. 可复用的基础

你需要领域知识和既定实践，以及你学会应用它们的方式

你的工作流程可能包括一套研究方案，或者团队在承诺交付日期之前遵循的步骤

知识系统应当对这些工作流程建模，以便你和智能体能够遵循并改进它们

你还需要一些方式，将智能体连接起来，并在你的数据之上构建视图，比如证据表或客户承诺的周计划

另一位研究者或顾问应当能够复用这一基础，并将其调整以适应自己的工作

@balajis 描述了其中的一部分：

查看原推文

但我认为远不止于此

把工作显性化，也为你围绕它塑造软件提供了基础

知识系统

知识系统汇集了：

这些部分可以共同发展

你正在构建一个环境，它既体现你所知道的东西，也体现你如何运用这些知识

设计这个环境，就是我所说的知识工作工程

智能体仓库

智能体仓库是一种将知识与操作这些知识的能力打包在一起的仓库

在 @arsumbrisai（我们正在构建的、面向知识系统的本地优先框架与工作空间）中，一个智能体仓库可以包含：

工具和界面的代码也可以放在同一个仓库里

这样你和智能体就能一边处理知识，一边构建你用来处理知识的环境

美妙之处在于，这些仓库可以像代码包一样相互依赖

因此，一个研究项目可以把方法库、主张提取包以及用于比较证据的 ui 组件组合在一起

你自己的论文和问题留在你的项目里

我们的类型引擎让 wikilinks 能够跨越这些仓库边界：

[[research methods::method-library]]

（这有多酷啊？！）

这解决了 method-library 依赖中的那条备注

引擎会解析链接，并能跨仓库检查类型化关系，因此分别维护的知识库会成为同一个可查询图的一部分

你可以在共享库所在之处基于它构建，然后把你自己的解读和工作留在你的仓库里

当然，一个包即使只包含一个可读的知识库，也可以单独发挥作用

把一个方法库与一个应用它的技能、以及一个审阅结果的界面组合起来，别人就能用他们自己的材料让这些知识发挥作用

让知识库像代码库一样运作

软件有一些方法能让不断增长的代码库变得可理解、可维护、可变更

我们希望为知识找到类似的模式：

ars umbris 通过类型引擎、智能体框架和宿主应用（工作区应用）将这些整合在一起

引擎将你的仓库作为一个类型化图谱来读取

它的诊断会给你和你的智能体提供反馈，例如：这条记录缺少必填字段，或者这个引用指向了错误类型的对象

智能体框架通过 mcp 提供工具，并以你的编码工具链所使用的格式交付技能

我们目前已经为 claude code 和 codex 提供了适配器

一切都是可扩展的，因此你可以与你的智能体协作，为另一个工具链构建适配器

编码智能体本就是为与代码库协作而构建的，它们在其中导航文件、进行更改并根据诊断采取行动

其假设是，以类似的方式组织领域知识和工作方法，能让这些智能体将同样的能力带到研究或经营公司中

为每个领域构建单独的工具链，也意味着要随着智能体工具的发展来维护该工具链

我们可以基于现有的工具链来构建，并将领域特定的工作集中在可复用的包中

而自定义应用需要有地方运行

如果你在客户笔记之上构建了一个 crm，你应该能够在已经使用的环境中打开它

宿主应用提供了这一运行时，并以图谱作为你应用的共享数据层

（事实上，你的应用/视图也是同一基底的一部分）

一个规划视图可以处理相同的承诺事项，而无需单独的数据库或托管设置

同一套类型系统描述你的知识、工具接口和视图配置

我们内置的工具和视图也使用了这些扩展机制

一次性的可视化可以帮助回答某个特定问题

你每周都在使用的视图可以成为工作空间中持久的一部分，与它们所支持的方法一起进行版本管理和改进

我认为这将成为 2027 年知识工作中最大的变革之一

智能体可以帮助你把一个有效的方法显式地表达出来，并编写应用它所需的软件

一个共享框架为这些软件提供了运行的地方，也让其他人可以在其基础上继续构建

将决策与其产生的工作关联起来

假设只要你在十二月之前交付某个特定功能，客户就会签约

你希望这个承诺始终与那个功能以及讨论它的对话保持关联

你可以用一个类型来描述它：

# commitment.type.yaml
fields:
  feature: feature*
  deadline: Date
  source: source*

feature 和 source 是你在工作空间中定义或复用的类型

星号表示对该类型对象的引用

deadline 使用了内置的 Date 类型

然后一篇 markdown 笔记就可以使用这个定义：

---
type: commitment
feature: "[[account export]]"
deadline: 2026-12-01
source: "[[acme sales call]]"
---

acme will sign if account export is available by december

这类似于在代码中定义一个对象必须具有的形状

引擎可以报告缺失的 source，或者与预期类型不匹配的引用

我们的自定义类型语言还允许你约束取值范围，并随着模型的发展扩展现有类型

现在把功能与其实现工作关联起来，并记录接受该承诺的决策及其背后的假设

销售可以使用管道视图，这是应用内用于查看和更新交易的一个组件

工程可以使用一个针对相关工作的规划视图

假设你后来得知某个集成所需的时间远超预期

智能体可以沿着这个结构追踪，并为你呈现信息以供审阅

你还得判断这个延迟意味着什么，以及该告诉客户什么

也许复盘会发现，你屡次在核实集成工作之前就做出交付承诺

于是你把这项核实加入审查新承诺的方法中，并让它的结果在决定被接受之前就可见

下一笔交易会受益于这一笔交易中发生的事

这项核实之所以存在，始终与促使你加入它的那段经历相连

构建一个随研究一同发展的研究环境

我们来看另一个具体的例子

设想与一位正在准备文献综述的研究者一起搭建一个工作空间

他们有十篇论文似乎都支持同一个结论，但其中几篇复用了同一份数据集，或重复了同一个原始结果

他们需要考察实际存在的独立证据究竟有多少

我们先从一项主张与一个来源之间的关系说起

下面是我一直在研究测试平台中探索的一个模型的简化版本：

# claim.type.yaml
fields:
  grounds: grounding&[+]

一项主张至少需要一条依据记录

每条依据记录都记载了某个来源就该项主张说了什么，以及该来源对它的了解有多直接：

# grounding.type.yaml
fields:
  of: source::au-base-types*
  stance: [asserts, denies, observes]
  basis: [observed, reported, inferred]

来源类型来自一个共享的基础包

这些列表定义了立场和依据的允许取值

依据区分了来源自身的观察与它所报告或推断出的内容

以一项虚构的研究为例，一条主张记录可能长这样：

---
type: claim
grounds:
  - ^: g1
    of: "[[feedback study^result-1]]"
    stance: asserts
    basis: observed
---

# the weekly-feedback group had a higher completion rate in this study

the paper reports a higher completion rate in its weekly-feedback group (see [[^g1]])
whether this carries over to our courses remains an open question.

（注：你也可以在这里创建一个带类型的问题对象并链接过去）

of 链接指向捕获来源中被标记的一段文字

依据就嵌在这条笔记里，但该类型也允许链接到一条独立的依据记录

^: g1 条目为这条依据赋予了一个 id

[[^g1]] 让正文能够指向那条特定的依据，当一项主张有多条依据时这很有用

如果智能体遗漏了依据，或使用了未知的立场，引擎可以将其报告出来

一个来源可能断言某项主张，也可能否认它

记录下这种归属，就使它可供审查

重要： 它并不裁定该主张是否为真，也不裁定来源是否真的支持它。但它为你或你的智能体提供了可以遵循并在语义上核查的结构

所以这些就是我们在这一研究实践中、利用引擎的构建块所定义的类型

我们可以发展这个模型，把论文与底层研究区分开，再把研究与其数据集连接起来

我们自己的问题和猜想也可以有自己的类型

一项提取技能可以指示智能体保留这些区分，并对照来源段落核查每一项主张

一个工具可以查询所记录的关系，找出共享同一项研究或数据集的主张

一个比较视图可以把它们的方法与结果并排放在一起

一个引文图可以提供另一种探索同一批材料的方式

研究者可以从十篇论文之间表面的一致，转向对其背后证据的调查

现在设想这次综述留下了某些未解决的问题

研究者记录下一个问题，设计出一个拟议的实验，并将其与正在被检验的假设连接起来

当结果到来时，它们加入同一个环境

之后的一次综述可以考察这些结果支持或挑战了哪些结论

而这些方法也可以拥有自己的知识库

一个研究方法包可以解释偏倚的来源，以及为什么不同的研究设计支持不同的结论

智能体可以在协助研究者设计类型或修订评审流程时参考它

例如，关于共享证据的知识可以指导提取技能记录哪些关系，以及查询工具寻找哪些模式

方法背后的推理可以与其应用能力一同传递

（顺便说一句，我没有科学研究背景。这是我第一次尝试为自己的研究构建一些东西，在这里用作演示）

我会如何开始构建一个知识系统

从一件你实际需要做的工作开始

假设你正在回顾上一季度，以决定接下来重点关注什么

把你的项目笔记和结果带入工作区，然后与智能体一起梳理你预期发生了什么以及实际发生了什么

将决策连同其支撑证据以及你想重新审视的开放问题一并保存下来

你的上下文和结构会在你完成回顾的过程中逐渐发展

然后审视那些始终相关的区分

如果一项决策依赖于某个假设，就把这种关系建模出来，以便日后重新审视

如果回顾遵循一套有用的步骤顺序，就把这些指令转化为一项技能

当某部分工作需要可重复的操作时，为它构建一个工具

当你总是想要一起查看若干相关对象时，围绕这项任务构建一个视图

我们还有一些早期包可供你在此基础上构建：

在另一个真实案例上试用这个系统

后来的结果可能会挑战早先决策背后的某个假设

这让你能检查系统是否帮助你恢复推理，并决定需要重新审视什么

从足以支撑工作的结构开始，然后在学习过程中不断修订它

将专业知识与其应用手段打包在一起

一旦某种工作方式被证明有用，你就可以把可复用的部分与你用来开发它们的特定工作分开

对于研究示例，这可能变成一个 evidence-review 包，包含：

研究者的论文、问题和实验结果留在它们自己的项目中

一旦这个包可用，研究项目就可以声明：

# .arsumbris/repo.yaml
name: my-research
deps:
  - name: evidence-review

项目中的一个主张随后可以使用 type: claim::evidence-review

限定符指明了提供该类型的包

引擎从包的 grounds 字段推断出嵌入的 grounding 类型

另一位研究者可以用自己的论文使用同一系统，然后针对其领域需要提出的问题进行扩展

这也为专家提供了一种将专业知识与其应用手段一起分发的方式

法律专家可以围绕某类特定审查构建一个包

该包可以将某个事项中的事实和文档与相关权威依据、解释和拟议变更连接起来

其方法将指导收集和检查什么，而其接口则帮助某人审视推理并决定接受什么

另一位专家可以用自己的事项使用并调整这套设置

一个包也可以只提供某一个有用的部分

一个领域知识体系、一项审查技能，或一个对其它包已使用的类型的视图

当这些包使用兼容的类型和关系时，你可以将它们组合起来

因此，对共享方法的改进可以惠及众多项目，而每个人仍保有自己的工作与扩展

工作留下的不只是眼前的成果

它还能留下有用的知识、一个经另一个真实案例检验过的方法，以及一个能更好承载这项工作的环境

后来的项目可以在此基础上继续发展

而一个可复用的包则让他人能从你所学到的东西出发，带着应用它所需的知识与能力

这就是我在知识工作工程中看到的机会

人与智能体可以既推进工作本身，也改进他们用来完成工作的系统

heinrich