分享一个辅助 agent 开发的小工具，给各位做垂直行业智能体的老哥
在金融、法律、医学、工程类的垂直领域，现在也需要一些做长任务的智能体了，所以，怎么给他们喂资料，就成了源头的一个需要斟酌的问题。
因为在现实环境里的资料，跟办公场景的比要粗糙多了。平时我们处理文档，很多都是把文档简单理解成一长串文字，在简单问答里够用，就行了。
但在真实工作里，是不够的。比方说，一份合同里，重要的不只是某个条款的句子，还有它属于哪一版？和哪个定义条款有关？例外条件在哪里？哪些批注已经接受？哪些还在审阅？
以及一份产品文档里，除了说明文字，还有版本、配置前提、截图、变更记录、上下游模块和还没关闭的问题。如果把这些东西都压成文本片段，很多信息在进入模型之前就已经丢了。
这种处理方式太过扁平，你可以理解为“二维”的，用在传统的软件那里还好，反正下一个任务又重新开始嘛。
但现在的 agent 不一样了，它要求你是智能化的、要越用越聪明的，要像人类实习生，教过一遍就要记得，下次干活就能用上，越干越熟练。所以就要求你的解析方式，也得进步，要引入时间、位置、来龙去脉、前因后果等等三维甚至四维的变量，还要帮 agent 形成记忆，不能我说一遍，啊，第二天又忘了，又要重新教，这样的 agent 不就跟猪一样了么。
所以，做长任务的 agent ，比做一次问答的 agent ，会更容易出问题：它能把一份报告里的数字搬进另一份 memo ，却不知道这个数字来自哪张表、是否已经更新、会不会让后面的结论失效。它能生成一段很流畅的文字，却不知道这段文字破坏了哪个引用、哪个前提、哪个还没定下来的决定。
这不是单纯的 RAG 的问题，也不是单纯的 context 不够，虽然上下文太短确实会看不全，但现在随着模型发展已经不是最大的限制了，最大的限制是它没有一个可以行动其上的外部世界。
我的解决办法也很简单，就是给它一个外部现实，对于企业场景，这个现实就是文档、版本、引用、表格、图片、批注、来源、权限和它们之间的关系。文档不是附件，文档是 Agent 要进入的工作现场，它大概包含：
```plaintext
Document
-> Section
-> Chunk
-> Asset(table/image/page/slide)
-> Metadata
-> Source path
-> Graph link
-> Retrieval trace
```
Document 让系统知道证据属于哪份材料，而不是一段孤立文本。Section 保留章节层级和语义范围。Chunk 是最小可检索内容，但它不能只保存 content ，还要保存位置、路径、类型和来源。Asset 让表格、图片、页面和 PPT 图示不从链路里消失。Metadata 保存页码、文件名、关键词、摘要和 chunk type 。Graph link 表达跨章节、跨文档、跨资产的基础关系。Retrieval trace 让一次回答可以回看证据路径。
如果系统维护了文档状态，Agent 可以做更细的动作：
```plaintext
search(query)
open_document(document_id)
expand_section(section_path)
inspect_asset(asset_id)
compare_chunks(chunk_a, chunk_b)
follow_edge(edge_id)
cite(source_path)
revise_query(reason)
```
我专门做了一个工具 Knowhere ，来完成这件事： [https://github.com/Ontos-AI/knowhere](https://github.com/Ontos-AI/knowhere) 。
当前的链路大概是这样的：
```plaintext
dirty documents
-> parse
-> hierarchy / sections
-> chunks / assets / metadata
-> graph
-> agentic retrieval
-> cited evidence
```
这个工具会把一次性的文件处理，变成 Agent 可以长期访问的文档状态，补的是记忆、检索和上下文这一层，让复杂文档以可被执行框架管理的形态进入系统：
```plaintext
Model: 负责语言推理和生成
Harness: 负责工具、状态、约束、执行边界
Knowhere: 把复杂文档建成可被 Harness 调用的记忆状态
Retrieval infra: 负责索引、召回、排序、存储性能
```
最后，整个解析工作就是这样：模型负责推理和生成，Harness 负责工具、上下文策略、执行边界和反馈循环。当 Agent 进入更长的任务和更复杂的材料环境时，Harness 里就分出一层文档 world state：文档、章节、chunk 、资产、来源、关系的可导航表征。Knowhere 让文档不再只是 prompt 里的一段附件，而是 Agent 可以反复回到、反复导航、反复引用的可操作状态。
模型会继续变强，材料也会继续变杂。但真正能进入知识工作的 Agent ，缺的不是更多上下文，而是一个可以行动的知识状态。
感兴趣的老哥可以体验一下： [https://knowhereto.ai/?utm_source=v2ex](https://knowhereto.ai/?utm_source=v2ex)
仓库在这里，开源小项目，欢迎各位随时反馈： [https://github.com/Ontos-AI/knowhere](https://github.com/Ontos-AI/knowhere)
---
原文链接：[点击查看](https://www.v2ex.com/t/1235362)
因为在现实环境里的资料，跟办公场景的比要粗糙多了。平时我们处理文档，很多都是把文档简单理解成一长串文字，在简单问答里够用，就行了。
但在真实工作里，是不够的。比方说，一份合同里，重要的不只是某个条款的句子，还有它属于哪一版？和哪个定义条款有关？例外条件在哪里？哪些批注已经接受？哪些还在审阅？
以及一份产品文档里，除了说明文字，还有版本、配置前提、截图、变更记录、上下游模块和还没关闭的问题。如果把这些东西都压成文本片段，很多信息在进入模型之前就已经丢了。
这种处理方式太过扁平，你可以理解为“二维”的，用在传统的软件那里还好，反正下一个任务又重新开始嘛。
但现在的 agent 不一样了，它要求你是智能化的、要越用越聪明的，要像人类实习生，教过一遍就要记得，下次干活就能用上，越干越熟练。所以就要求你的解析方式，也得进步，要引入时间、位置、来龙去脉、前因后果等等三维甚至四维的变量，还要帮 agent 形成记忆，不能我说一遍，啊，第二天又忘了，又要重新教，这样的 agent 不就跟猪一样了么。
所以，做长任务的 agent ，比做一次问答的 agent ，会更容易出问题：它能把一份报告里的数字搬进另一份 memo ，却不知道这个数字来自哪张表、是否已经更新、会不会让后面的结论失效。它能生成一段很流畅的文字，却不知道这段文字破坏了哪个引用、哪个前提、哪个还没定下来的决定。
这不是单纯的 RAG 的问题，也不是单纯的 context 不够，虽然上下文太短确实会看不全，但现在随着模型发展已经不是最大的限制了，最大的限制是它没有一个可以行动其上的外部世界。
我的解决办法也很简单，就是给它一个外部现实，对于企业场景，这个现实就是文档、版本、引用、表格、图片、批注、来源、权限和它们之间的关系。文档不是附件，文档是 Agent 要进入的工作现场，它大概包含：
```plaintext
Document
-> Section
-> Chunk
-> Asset(table/image/page/slide)
-> Metadata
-> Source path
-> Graph link
-> Retrieval trace
```
Document 让系统知道证据属于哪份材料，而不是一段孤立文本。Section 保留章节层级和语义范围。Chunk 是最小可检索内容，但它不能只保存 content ，还要保存位置、路径、类型和来源。Asset 让表格、图片、页面和 PPT 图示不从链路里消失。Metadata 保存页码、文件名、关键词、摘要和 chunk type 。Graph link 表达跨章节、跨文档、跨资产的基础关系。Retrieval trace 让一次回答可以回看证据路径。
如果系统维护了文档状态，Agent 可以做更细的动作：
```plaintext
search(query)
open_document(document_id)
expand_section(section_path)
inspect_asset(asset_id)
compare_chunks(chunk_a, chunk_b)
follow_edge(edge_id)
cite(source_path)
revise_query(reason)
```
我专门做了一个工具 Knowhere ，来完成这件事： [https://github.com/Ontos-AI/knowhere](https://github.com/Ontos-AI/knowhere) 。
当前的链路大概是这样的：
```plaintext
dirty documents
-> parse
-> hierarchy / sections
-> chunks / assets / metadata
-> graph
-> agentic retrieval
-> cited evidence
```
这个工具会把一次性的文件处理，变成 Agent 可以长期访问的文档状态，补的是记忆、检索和上下文这一层，让复杂文档以可被执行框架管理的形态进入系统：
```plaintext
Model: 负责语言推理和生成
Harness: 负责工具、状态、约束、执行边界
Knowhere: 把复杂文档建成可被 Harness 调用的记忆状态
Retrieval infra: 负责索引、召回、排序、存储性能
```
最后，整个解析工作就是这样：模型负责推理和生成，Harness 负责工具、上下文策略、执行边界和反馈循环。当 Agent 进入更长的任务和更复杂的材料环境时，Harness 里就分出一层文档 world state：文档、章节、chunk 、资产、来源、关系的可导航表征。Knowhere 让文档不再只是 prompt 里的一段附件，而是 Agent 可以反复回到、反复导航、反复引用的可操作状态。
模型会继续变强，材料也会继续变杂。但真正能进入知识工作的 Agent ，缺的不是更多上下文，而是一个可以行动的知识状态。
感兴趣的老哥可以体验一下： [https://knowhereto.ai/?utm_source=v2ex](https://knowhereto.ai/?utm_source=v2ex)
仓库在这里，开源小项目，欢迎各位随时反馈： [https://github.com/Ontos-AI/knowhere](https://github.com/Ontos-AI/knowhere)
---
原文链接：[点击查看](https://www.v2ex.com/t/1235362)
评论
暂无评论。