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

推荐订阅源

Recent Announcements
Recent Announcements
人人都是产品经理
人人都是产品经理
月光博客
月光博客
博客园 - 三生石上(FineUI控件)
GbyAI
GbyAI
博客园 - 司徒正美
美团技术团队
Vercel News
Vercel News
IT之家
IT之家
U
Unit 42
Y
Y Combinator Blog
罗磊的独立博客
Microsoft Security Blog
Microsoft Security Blog
MongoDB | Blog
MongoDB | Blog
Jina AI
Jina AI
V
Visual Studio Blog
B
Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
MyScale Blog
MyScale Blog
博客园 - 叶小钗
A
About on SuperTechFans
WordPress大学
WordPress大学
Hugging Face - Blog
Hugging Face - Blog
B
Blog RSS Feed

V2EX

我用 AI 写代码,但终端管理反而成了累赘——于是我做了 codux [调研] 各位在公司都用什么 ide 和 agent 写代码? 老运维 share 一个运维平台 看到有公司考核 token 指标,很好奇大家上个月的 AI 账单是多少 GLM-Coding 调用持续报错: z.ai 的 Lite 套餐几乎无法使用,官方 Pro/Max 是否稳定? 现在还有什么渠道可以稳定安全地使用 Claude 吗? 上海漕河泾内推,本组有 2 个 hc,一个后端,一个前端,预算都是 20k 左右,不打卡,氛围好 如果 V2EX 上有一组不永久保存聊天记录(比如只保存 7 天或者 24 小时)的聊天室,那么会开启哪些有用或者有趣的可能? gemini cli 貌似挂了,一直返回 403 第一次在自媒体上赚到钱 收集了最近在使用的低价 GPT, Gemini,邮箱等 AI 会员的小店合集 讨论个大实话:现在企业还在说 AI 编程提效 20%, 30%的,真的太落后,没用懂 AI。因为包括很多前沿公司,已经狂奔到提效 200%-500%的情况 [招聘][远程][币安] 前端/后端/QA/iOS/Android 至少 3 年以上经验 目前有大量 HC 欢迎投递 Chatgpt Pro 用量用不完的可以开这些设置 面试的时候好像遇到钓鱼了,给各位避个坑 cursor 年续费 22 号到期, 自动续费是否还是老的计次套餐呢 被两件破事毁掉的一下午,琐碎的内耗消磨人的精力 使用 Planet 存储 Codex 的会话或者重要信息 如果业务部门领导不要你开发功能,而是要求你教会它用 claude code 开发功能,你会怎么做? 分享一个 MacOS 接绿联 CM818 USB 转 DP 转接器使用感受 我的 HR 朋友 10 年老 Java ,非全大专,大家帮忙看看简历 开源了一个 AI 口语练习工具,音素级发音评分,完全免费可自部署 V2EX 上有哪些你觉得很有趣、印象深刻的妹纸? 字节为啥不出个国内版 Vercel? 有在大马的朋友吗? 问个运营商问题 你们在有领导的公司大群发过的最大胆的消息是什么 公司裁员,目前没有工作。想试试摆摊,做一个移动鲜啤打酒车 我的硬盘 Memblaze Pblaze 5 Linux 下不识别,给 Linux 内核提交了补丁, AI 说有望被合并 只有我一个人觉得 codex 不好用?
分享一些 agent 开发中常遇到的解析问题 - V2EX
cxd8190102 · 2026-06-13 · via V2EX

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

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

一份投资 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