惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
Y
Y Combinator Blog
Engineering at Meta
Engineering at Meta
D
Docker
GbyAI
GbyAI
aimingoo的专栏
aimingoo的专栏
大猫的无限游戏
大猫的无限游戏
腾讯CDC
P
Proofpoint News Feed
A
About on SuperTechFans
WordPress大学
WordPress大学
Stack Overflow Blog
Stack Overflow Blog
Google DeepMind News
Google DeepMind News
C
Check Point Blog
Microsoft Security Blog
Microsoft Security Blog
H
Hackread – Cybersecurity News, Data Breaches, AI and More
L
LangChain Blog
MyScale Blog
MyScale Blog
博客园 - 三生石上(FineUI控件)
Hugging Face - Blog
Hugging Face - Blog
Microsoft Azure Blog
Microsoft Azure Blog
N
Netflix TechBlog - Medium
G
Google Developers Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻

程序员

V2EX 看到讨论"跨域"的帖子,那个她好像回来了 codex 今天真的是不稳定呀。 火山方舟 Coding Plan 慎买 刚问了大家 openclaw 和 hermes 在什么机器上面玩,求推荐一个机器 GPT-image-2 生成 AI 图片防伪有感 codex pro 5 小时限制已经严重缩水 逆天 Antigravity 动态 JSON 序列化对强类型语言很难吗? 自建了 GPT Coding Plan,遇到了定价问题,请教大家 大家都是在什么设备上玩 openclaw 以及 hermes 的呀? 软考还有一个月就考试了,你们学习了吗? 大伙用 AI 会考虑在 user scope 的 CLAUDE.md/AGENTS.md 里交代 AI 说中文吗 我发现程序员这个群体很大部分其实挺抠的 最近使用 cc 总会莫名其妙的返工, codex 不会 目前体验最好的远程 vibe 工具 想知道大佬们抓包遇到 ssl pinning 都是咋优雅的 解决的? 工业软件的大佬们是怎么 vibe coding 的 最近 chrome 是不是有 bug 啊,一搜索就卡住 分布式异步系统在 vibe coding 下的困境 PHP Native AOT 编译器,支持将 PHP 代码编译为可执行文件,运算性能提高 150 倍 没想到 2026 年,还要浪费大量时间在跨域问题上 DeepSeek V4 这周会出吗? 中转站正式试营 欢迎试用 不掺不假 小米 mimo 升级 v2.5,并且重置了额度 Jenkins, SCM 轮询完全不工作是啥问题啊 赛博斗蛐蛐, AI 模型的简单对比(白嫖版) 使用中转站要擦亮眼睛!不说别的,倍率计算 充值好乱。 买了火山的 Coding Plan 测试得出计费模式 给我的 AI 生成了简历和状态卡, 大家帮忙看下 Ta 能找到啥样的
分享一些 agent 开发中常遇到的解析问题 - V2EX
cxd8190102 · 2026-06-13 · via 程序员

我们平时说“处理文档”,很容易把文档理解成一长串文字。这个理解在简单问答里够用,但在真实工作里很快就不够了。

比方说,一份合同里,重要的不只是某个条款的句子,还有它属于哪一版?和哪个定义条款有关?例外条件在哪里?哪些批注已经接受?哪些还在审阅?

一份投资 memo 里,重要的不只是结论,还有这个结论依赖哪张表、哪个市场假设、哪份访谈记录?以及这些假设有没有被后来的数据推翻?

以及一份产品文档里,除了说明文字,还有版本、配置前提、截图、变更记录、上下游模块和还没关闭的问题。如果把这些东西都压成文本片段,很多信息在进入模型之前就已经丢了。

这种处理方式太过扁平,你可以理解为“二维”的,用在传统的软件那里还好,反正下一个任务又重新开始嘛。

但现在的 agent 不一样了,它要求你是智能化的、要越用越聪明的,要像人类实习生,教过一遍就要记得,下次干活就能用上,越干越熟练。所以就要求你的解析方式,也得进步,要引入时间、位置、来龙去脉、前因后果等等三维甚至四维的变量,还要帮 agent 形成记忆,不能我说一遍,啊,第二天又忘了,又要重新教,这样的 agent 不就跟猪一样了么。

所以,做长任务的 agent ,比做一次问答的 agent ,会更容易出问题:它能把一份报告里的数字搬进另一份 memo ,却不知道这个数字来自哪张表、是否已经更新、会不会让后面的结论失效。它能生成一段很流畅的文字,却不知道这段文字破坏了哪个引用、哪个前提、哪个还没定下来的决定。

这不是单纯的 RAG 的问题,也不是单纯的 context 不够,虽然上下文太短确实会看不全,但现在随着模型发展已经不是最大的限制了,最大的限制是它没有一个可以行动其上的外部世界。

我的解决办法也很简单,就是给它一个外部现实,对于企业场景,这个现实就是文档、版本、引用、表格、图片、批注、来源、权限和它们之间的关系。文档不是附件,文档是 Agent 要进入的工作现场,它大概包含:

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 可以做更细的动作:

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

当前的链路大概是这样的:

dirty documents
  -> parse
  -> hierarchy / sections
  -> chunks / assets / metadata
  -> graph
  -> agentic retrieval
  -> cited evidence

这个工具会把一次性的文件处理,变成 Agent 可以长期访问的文档状态,补的是记忆、检索和上下文这一层,让复杂文档以可被执行框架管理的形态进入系统:

Model:           负责语言推理和生成
Harness:         负责工具、状态、约束、执行边界
Knowhere:        把复杂文档建成可被 Harness 调用的记忆状态
Retrieval infra: 负责索引、召回、排序、存储性能

最后,整个解析工作就是这样:模型负责推理和生成,Harness 负责工具、上下文策略、执行边界和反馈循环。当 Agent 进入更长的任务和更复杂的材料环境时,Harness 里就分出一层文档 world state:文档、章节、chunk 、资产、来源、关系的可导航表征。Knowhere 让文档不再只是 prompt 里的一段附件,而是 Agent 可以反复回到、反复导航、反复引用的可操作状态。

模型会继续变强,材料会继续变杂。但真正能进入知识工作的 Agent ,缺的不是更多上下文,而是一个可以行动的知识状态。

感兴趣的老哥可以体验一下: https://knowhereto.ai/?utm_source=v2ex

仓库在这里,开源小项目,欢迎各位随时反馈: https://github.com/Ontos-AI/knowhere