Agent 这个词，其实已经被拆成了两面。

一半活在 Anthropic 的博客里，活在 Claude Code 被逆向泄露出来的代码里，活在 Hermes 开源的自进化机制里。每周都有新的 Harness 概念冒出来，每个月都有新 SOTA 刷新。

另一半活在你的工位上。

你的老板、你的产品经理，把一篇篇“颠覆”“炸裂”“国运级”的自媒体文转到群里，问我们为什么做不到这个？？？

比如，老板说，

• Agent都能自动写代码了，我们的合同审核流程为什么还要填模板
• 人家 Hermes 都能自进化了，我们的工作流是不是也能进化一下
• 那篇文章写的multi-agent 提升 90%，我们也要做multi agent

你头皮发麻。因为对你来说，目前手上的项目，那些前沿架构、那些炸裂文渲染的效果，几乎一条都用不上。不是借鉴一下能用，不是改改就能用，是字面意义上的一条都用不上。

这道鸿沟，困扰着几乎所有开发企业级 Agent 的人。

---

鸿沟在哪，你抄不动的真正原因

Claude Code、OpenClaw、Hermes，这些今天刷屏的前沿 Agent，没有一个是为企业级场景设计的。

它们的真实目标用户只有两种人：

• **写代码的程序员，**无论是自己的项目还是公司的代码库
• **能像程序员一样操作环境的个人用户，**会用命令行、看得懂日志

注意这两类的共同点，任务的所有者就是任务的执行者。我自己写代码、我自己点确认、我自己审结果。Agent 是我的延伸，我能即时验收、即时纠正、即时撤销。

它们活在一个干净的世界里。

拿 Coding 举例，cat 一定能读到文件，pytest 一定告诉你 pass 还是 fail，编译错了 stderr 一行字告诉你为什么错。

对和错有客观裁判，裁判叫编译器和测试用例。

Agent 跑歪了大不了 git revert，试错成本几乎为零。Reflection、self-correction、ReAct，所有模式，都建立在环境本身就有清晰反馈的前提上。

你做的企业 Agent 不在这个世界里。

你的工具，是公司内部 HR 系统三年没更新的 API，返回字段叫 rsltCd，值 0000 表示成功、0001 表示部分成功，而部分成功是什么意思没人知道，写这个接口的同事去年离职了。

你的数据，是 CRM 里几万份扫描件，文件名是 合同-最终版-改-真的最终版-v3(1).pdf，2018 年扫的，有的页面是斜的，有的签名和标注糊得看不清。

你的反馈，是业务主管下午开会时说这个不对，但我得再确认下，然后下周才给你个几百字的回复。没有 test 可以跑，没有明确的终止条件，连对错本身都要协商。

你的错误，是不可恢复的。漏审一条违约金条款，可能会造成客户的重大损失，政务问答答错一次，第二天引发舆论风险。现实世界没有 git revert。

这就是两个 Agent 的真正区别：

**Claude Code 和 Hermes 做的是干净世界 → 干净世界的翻译，**把程序员的意图翻译成代码动作。两头都是结构化、可验证、可回滚的。

**你做的是脏世界 → 干净世界的翻译，**把业务方含糊的口头需求，翻译成脏数据上的具体动作。一头模糊，一头要求精确；一头延迟，一头要求实时；一头不可逆，一头要求可追责。

这是两件根本不同的事。但所有 Agent 博客、所有 Agent 框架、所有 Agent paper，写的全是第一件事。因为写博客的人是程序员、框架的作者是程序员、paper 的评审也是程序员。他们写的是他们自己的世界。

所以你抄不动：

• 按 LangGraph 搭了工作流，能勉强跑通。但中间每个节点维护难度大，牵一发而动全身。每次有了新需求，迭代周期越来越长。
• 按 Anthropic 博客搭了 multi-agent，死循环烧光了你这个月的 API 预算。

Claude Code 能 reflection，因为它每一步都能跑代码、看输出、即时自我修正。你的合同审查 Agent reflection 给谁看？业务方早上收到消息，下午才回你一次。

Hermes 能 skill discovery，因为 skills 都是结构清晰的 markdown，可以列表、可以读取、可以 patch。你的行业规范是什么形态？一份 PDF，一份扫描件，一份 Word 里嵌着图。光是沉淀Skill这个过程，就能耗光你的Token，并且识别不了所有的长尾情况。

Cursor 能开发Agent mode，是因为代码库有 AST、有 LSP、有 type system。但客户那边的所谓知识库是 5000 份格式不一的内部文档，其中 800 份是同一份文件的不同版本。

不是你水平不行，是那些方法论假设的前提，你的项目里一条都不成立。

---

那怎么办？先看清你真正面对的是什么

我帮企业做过十几个 Agent 项目，囊括了很多现实的企业级需求，合同审查、合规检查、招投标辅助、政务问答。每一个项目翻开，面对的都不是模型选型、Prompt修改、Harness怎么兜底等问题，而是同时撞上的五堵墙。

先说这五堵墙是什么。它们不和后面的五层 Harness严格一一对应。

五堵墙是问题，五层 Harness 是解法，问题和解法之间从来不是 1：1 映射。但你必须先看清这五堵墙，才能理解为什么后面要那样设计。

第一堵墙：数据是脏的，而且你低估了有多脏。

你以为是几百份 PDF，真做起来才发现，30% 是扫描件，15% 是 Word 里嵌着截图的扫描件，5% 是图片格式的扫描件再被人截了图。文件名互相矛盾，最终版有 4 个，v2比v3还新。光是搞清楚哪个文件是当前有效版本，就要先做半个月的数据治理。这个问题很多团队都很重视，但很多团队既没有资源做，也没有时间做。更严重的是，没有一个合理的方法论，来指导数据治理。

第二堵墙：半结构化数据，两头不靠。

完全结构化的数据，数据库表你可以做一个SQL Agent。完全非结构化的数据，自由文本，LLM 反而好处理。最难的是中间那层，有格式但格式不严格，有结构但结构会破。表格里某一行突然变成合并单元格，条款编号编到 3.2.1 之后突然冒出来一个 3.2.1.附，段落里嵌着参见上文第二章但根本没有第二章只有第贰章。

正则解不动，LLM 看不全，这就是中间地带的诅咒。

第三堵墙：长上下文是个伪命题。

模型厂商告诉你支持 100 万 token。但凡你真往里塞过 80 万 token，你就知道：模型不是处理了这 80 万，它是扫了一眼。需要的关键信息只要不在开头不在结尾，大概率就丢了。

Coding Agent 没这个问题，因为一个文件就几千行。即使是要读大量的Coding和Tool Result，Agent层面无非也就是判断下哪些内容重量，然后拼接在Prompt的最后。

但你的世界不是。你的一份招标文件 300 页，法规附件 50 份，历史中标案例 2000 个，加起来轻松破百万 token，哪个都不能忽略，哪个都十分重要，模型在里面跟瞎子摸象一样。

第四堵墙：业务逻辑本身就是模糊的。

理论上，法规条款 A 对应报告段落 B，逐条匹配就行。实际上，法规写的是合理期限，业务方问你合理是几天。法规说应当设置明显的安全警示标志，业务方问你什么叫明显。每个公司内部的制度，和现实犯规又有冲突，内部制度也没有完整的数字化文件给你。

这些模糊性不是 bug，是业务逻辑本身。 法律就是这么写的，因为它必须留解释空间。你的 Agent 不能假装规则是清晰的，因为规则本来就不清晰。这一点 Coding Agent 永远不会遇到，代码不模糊，要么编译过要么编译不过。

第五堵墙：用户既要又要还要。

要准：漏一条就是事故。要快：等 30 秒就开始催。要便宜：token 预算砍了一半还要砍。要简单：不写 prompt，不给示例，甚至说不清自己要什么，你就按我们平时的标准来。

你做的不是 Agent。你是在四个互相矛盾的需求之间，找一条能走的路。

这五堵墙，不是某个项目的特例。是每一个做企业 Agent 的工程师，迟早会撞上的。

---

解法不在模型里，在 Agent 系统工程里

换模型解决不了这五堵墙。

下一代开源模型再便宜，业务逻辑一复杂照样跑偏。

Claude 再强，价格摆在那里，客户每月预算就 8000 块。下一代闭源模型出来，也不一定能替业务方把“明显”这个词定义清楚，更不能替你管理上下文窗口。

解决这些问题的，是模型之外的整套系统工程。它至少包含四种不同性质的层：

• 数据工程，脏数据怎么变成可查询、可审计的资产。这一层跟 LLM 几乎无关。
• Harness，Agent 跑起来之后，上下文怎么调度、工具怎么编排、流程怎么控制、错误怎么兜底。这一层才是严格意义上的 Harness，Claude Code 和 Hermes 卷的也是这一层。
• 业务工程，模糊的业务逻辑怎么翻译成显式、可版本化、可协商的判断标准。这一层是 LLM 和业务方之间的翻译层。
• 产品设计，用户预期怎么管理、确定性怎么交付。这一层决定项目能不能上线。

这四层里，Harness 只是其中一层。但今天所有的 Agent 博客、所有的开源框架、所有的 paper，**几乎只在卷 Harness 这一层，**因为在干净世界里，只有这一层是瓶颈。

而在你的脏世界里，Harness 卷到极致也解决不了前三堵墙。你需要的不是更强的 Harness，是把这四层一起垒起来。

下面是我总结的五层落地工作。每一层我都会标注它的真实归属，以免你在向上汇报或者招人的时候用错术语。先警告一句：这五层不是套用的模板，是一套提问框架。每一层我都会告诉你新手最容易掉的坑是什么。

另外，这五层之上还覆盖着一道贯穿全程的东西，评估。没有评估，你做的不是工程，是玄学。这件事文末单独讲，但你读下面五层的时候，脑子里先挂着这个问题：我每做一步，怎么知道做对了？

---

第一层，脏数据预处理管道，让 LLM 远离原始数据

新手最大的错觉是，现在多模态 LLM 这么强，直接在Agent中，把 PDF 扔给它不就行了？

多模态 LLM 在清晰扫描件上的识别率，确实已经追平甚至超过传统 OCR。所以准确率不是反对它的理由。

但在企业场景下，直接喂多模态 LLM 有三个绕不过去的硬伤：

第一，它是黑盒，你拿不到中间产物。

Claude 输出一条审查结论，你不知道它实际看到了什么，有没有看清第 23 页那个被盖章盖住一半的金额、有没有把违约金 50 万看成500 万，你不知道，它也不告诉你。出了事故，法务问你这条结论怎么来的，你只能回答模型这么说的，这种回答在合规场景下完全站不住脚。

而传统管道里，OCR 文本你能 diff，版面解析你能可视化，字段抽取的结果你能存成 CSV 对照原文。每一步出错都能定位到具体哪一页哪一行。

第二，它不可复现。

客户三个月后告你漏审一条条款，导致他被罚款，你要回答当时 Agent 看到的是什么、为什么得出那个结论。

直接喂多模态 LLM，你重跑一次结果可能跟上次不一样，模型版本在悄悄升级，图像理解的细节每次有偏差，temperature 设 0 也不是完全确定的。你没法复现当时的现场，在法律上就是举证失败。

而预处理管道是幂等的，同一份 PDF 进去，OCR 出来的文字一字不差，版面解析的结构一模一样，字段抽取的结果完全相同。事故现场能完整重放。

在合规场景下，确定性不是优点，是底线。

第三，数据不只是给 Agent 用的。

你以为你在做一个 Agent，实际上你在为一家公司建数据资产。同一批合同，法务部门要审，合规部门要查，业务部门要做画像，审计部门下季度要抽查。

如果你直接把数据扔给 LLM，在Agent中给出结论，这些数据用完就丢了，沉淀不下任何东西。下次别的部门来要，你还得重新跑一遍，再烧一遍 token。

而做了离线的预处理管道，你产出的是结构化数据资产，文档图谱、字段索引、引用关系。可以被审计、被复用、被增量更新、被传给下游别的系统。Agent 只是这些数据的第一个消费者，不是唯一一个。

所以这一层的正确做法是：

• 文档解析：PDF 用专业库提文本+表格+图片，扫描件走 OCR 流水线，默认用专业 OCR，把多模态 LLM 留给真正需要看图理解的场景，比如手绘图、印章重叠区域、识别盖章是否完整，Word 转纯文本+保留结构标记。
• 结构化索引：章节树、图表位置、交叉引用关系，全部建成可查询的图谱。不是把全文塞进向量库就完事，向量召回精度对企业文档来说远远不够，你需要的是基于结构的精准定位。
• 分级存储：原文一份，摘要一份，索引一份。LLM 永远不直接读原文，只通过索引定位到需要的片段再读。

这一层做完，你不再面对一堆文件，你面对的是一个可查询、可审计、可复用的文档图谱。

这一层最反共识的一点，它跟 LLM 没关系。它是数据治理。它是脏活累活，写 PPT 拿不出去吹。但这一层做不好，后面四层全是空谈。我见过的 Agent 项目里，80% 的失败都死在这一层。

尽管很多团队都理解这层工作的重要性，但是能做好，有资源有时间做的团队真的特别少，导致各个团队在整个项目开发周期中，都在为这层技术负债买单。

---

第二层，混合解析，结构化的归规则，模糊的归 LLM

这一层的核心问题是，哪些字段交给规则、哪些字段交给 LLM。

新手的直觉是：现在 LLM 这么强，全交给它不就行了？ 你能这么干，但你不该完全这么干。

一份合同里，有些字段是本质上确定的，金额、日期、条款编号、当事人名称、签署地点。这些字段在原文里就是黑纸白字写着的，不需要理解。

把确定的字段交给 LLM，你在做三件蠢事：

• 你把确定变成了不确定。 正则抽500万，100 次都是 500 万。LLM 抽500 万，99 次是 500 万，1 次可能给你来个 5000 万，这 1 次就是上电视的事故。
• 你把可审计变成了不可审计。 审计问为什么这个字段是 500 万，规则的答案是匹配到原文第 X 页第 Y 行，LLM 的答案是模型这么判断的。后者过不了任何合规审查。
• 你把可维护变成了不可维护。 规则错了改一行代码，所有历史数据重跑结果完全一致。LLM 错了你只能改 prompt，改完不知道有没有副作用。修好了这个客户的问题，可能引入三个别的客户的新问题。

而模糊的字段，本合同项下的合理使用范围、乙方应在合理期限内交付、如发生不可抗力，这些字段在原文里就没有确定答案。它们需要被理解、被解释、被结合上下文判断。这才是 LLM 该上场的地方。

落地方法：

• 结构化字段(金额、日期、编号、章节标题)→ 正则 + 解析器，100% 确定，零 token 消耗，可审计可回滚。
• 模糊文本(自由表述、隐式引用、需要推理的条款)→ LLM，但只给相关片段，不给全文。
• 两路结果在索引层合并。LLM 看到的输入是这是规则已确认的结构化字段 + 这是需要你理解的自由文本，而不是这是一坨 PDF，你看着办。

一句话总结，LLM 是用来吸收不确定性的，不是用来制造不确定性的。 如果确定性的规则没法保证所有的场景解析出结果，那么就进行LLM+规则的交叉验证，通过堆叠方式，把不确定性降到0。

---

第三层，长上下文的治理，别迷信100 万 token

模型厂商现在动不动告诉你我们支持 100 万 token。这话不假，但你要懂它的潜台词。

厂商测的是 needle-in-a-haystack，在 100 万 token 里塞一根针，问模型针在哪。这种找事实的任务，长上下文模型确实能做。

但你的业务任务不是找针。你的任务是：

• 这份 300 页的招标文件里，有没有任何两条条款相互矛盾？(多跳关系推理)
• 法规第 12 条和合同附件 3 的第 7 款，执行口径是否一致？(跨文档比对)
• 这份合同里乙方的所有义务，是否都有对应的违约条款？(完整性核查)

这些任务在长上下文下，模型性能会断崖式下降。RULER、NoLiMa 这些 benchmark 都验证过，号称 128K 的模型，做需要推理的任务时有效窗口可能只有 8K-16K。号称 1M 的模型，真正能做复杂推理的窗口也就 32K 上下。

不是模型在骗你，是找一个事实和推理多个事实之间的关系完全是两种任务。

所以你必须分治：

• 按章节/主题/条款拆成独立片段，每个片段控制在有效推理窗口内(经验值 8K-32K，不是厂商标称的那个数字)
• 每个片段配上它需要的上下文，引用了哪些其他段落、被哪些段落引用，这是图，不是树
• 推理结果在顶层汇总，而不是在底层交叉。底层只做这一段是否符合标准 X，汇总层才做整份文档是否一致

反共识点，Coding Agent 的读 → 改 → 测 → 提交是线性的，因为代码库自洽，编译器会告诉你这里对不上。业务文档不是，它们互相引用、互相依赖，但没有编译器。所以你的 Harness 不能线性处理，必须做图遍历：先建引用图，再按依赖顺序审查，最后汇总。

照搬 Coding Agent 的线性 ReAct 循环到你这里，死循环是必然的。

---

第四层，模糊逻辑的规则化，让 LLM 做判断，不让 LLM 做定义

合理期限、明显的安全标志、必要时、重大不利影响，这些模糊词是企业业务逻辑的核心，不是 bug。法律就是这么写的，因为它必须留解释空间。

新手的做法是：把这些词原封不动塞给 LLM，在 prompt 里写请判断合同中的违约金条款是否合理。

这会出三个事：

1. 不一致。 同一份合同跑两次，可能给出不同结论。LLM 哪怕设了 temperature=0，对合理这种主观词的判断，跨次调用、跨模型版本都不稳定。
2. 不可解释。 业务方问为什么你判断这条不合理，LLM 给你一段含糊的基于行业惯例和合同上下文。业务方一脸懵，你也一脸懵。
3. 不可协商。 业务方说你这个判断标准太严了，放宽一点，你怎么改？改 prompt？改完哪里变松了哪里变严了，谁也说不清。

业务方真正需要的不是聪明的判断，是可讨论的判断。

正确的做法是把模糊翻译成显式的判断标准：

1. 对每个模糊条款，离线用 LLM 生成 3-5 个具体化的判断标准。比如违约金合理翻译成违约金不超过合同金额的 30%、违约金计算方式明确写出、违约金有触发条件且条件可量化等等。
2. 这些标准跟业务方一起 review，改到双方都认可。这一步业务方必须在场，不是工程师拍脑袋。
3. 审查时，Agent 不判断是否合理，只判断是否满足这些显式标准。
4. 标准本身是配置化的、可版本化的、可追溯的，业务方看到结果不对，改的是标准，不是 prompt，改完每个历史 case 都能用新标准重跑一遍。

注意，LLM 仍然在做判断，判断这条违约金有没有写明计算方式对它来说还是需要语义理解的。但它判断的是一个明确的、可被业务方理解和修改的标准，而不是一个模糊的、只有它自己懂的合理性。

一句话总结，让 LLM 做判断，不让 LLM 做定义。 定义留给业务，判断交给模型。这两件事一旦混在一起，你的 Agent 就变成了一个谁也说不清、谁也改不动的黑箱。

---

第五层：用户预期管理，你卖的不是 Agent，是确定性

用户要快、要准、要便宜，这三个不可能同时满足。但你可以让用户自己选：

• **快速模式，**粗筛 + 关键词匹配 + 规则引擎，不调 LLM，秒级返回，覆盖 80% 的明显问题
• **标准模式，**LLM 逐条审查，分钟级返回，覆盖 95%
• **深度模式，**多模型交叉验证 + 强制人工复核挂钩，小时级返回，覆盖 99%

注意这三个模式不是三套独立系统。它们共用同一套预处理管道、同一套索引、同一套规则化标准，区别只在调度策略：调不调 LLM、调几次、要不要多模型交叉、要不要挂人工。前面四层做得越扎实，这里切换模式的成本越低。

用户不是真的要又快又准又便宜，这是不可能三角，他自己也知道。用户真正要的是知道什么时候能拿到什么质量的结果。

你给他一个黑箱，等 30 秒他就开始催。你给他三个明确选项，他就从为什么这么慢变成我选标准模式，心理预期一旦明确，催促就消失了。

这层是产品设计，不是工程。但 90% 的 Agent 项目死在这里。工程师把工程做完了扔给业务方，业务方一句太慢就把整个项目毙了。

你做的不是 Agent 产品，是确定性产品。 用户为之付费的不是AI 多聪明，是我知道交给你之后会发生什么。这一点想通了，前面四层的所有工程努力才有意义。

---

怎么知道你的 Agent 做对了没有？

前面欠的债，现在还。

Coding Agent 有 test。跑过了就是过了。SWE-Bench 给你一个数字，67.3%，一目了然。

你的合同审查 Agent 有 test 吗？没有。因为正确的审查结果本身就不存在，两个法务审同一份合同，结论可能不一样。

那你怎么知道你的 Agent 到底行不行？

这个问题不回答，前面五层全是空谈。你建了预处理管道、做了分治策略、规则化了模糊逻辑，然后呢？上线了，老板问效果怎么样，你只能回答感觉还行。

评估业务 Agent 不能用 Coding Agent 那套，但可以换一套。我用了一年，验证过四种思路：

第一，和基线比，不追求完美。

你的 Agent 不需要 100% 准确。它只需要比没有 Agent 的时候好。你们公司现在怎么审合同？人工一份多久？漏审率多少？这就是基线。Agent 上线后，同样的指标跑一遍。快了 30% 就是有效果，漏审率降了 50% 就是有效果。

不需要完美，只需要比昨天好。 这一条听起来废话，但 90% 的团队不做基线测量，然后就被业务方一句还不如人工审得仔细打回去重做。

第二，量置信度，不量准确度。

有些条款 Agent 判断不了。这不是失败，人类法务也判断不了。重点是 Agent 能不能诚实地告诉你我不知道。

一个好的 Agent 应该长这样：高风险条款揪出 80%、不误报；低风险条款自动放行、不出错；中间那部分老老实实标建议人工复核。它的价值不在于 100% 准确，在于把人类的精力集中在真正需要判断的地方。

一个把所有条款都自信地给出结论的 Agent，反而是最危险的。

第三，做盲测，不做自评。

不要用同一个模型审查完再让同一个模型打分，这是自欺欺人，但我见过的项目里 70% 都这么干。

正确做法：拿一批已经人工审查过的历史案例，让 Agent 独立审查，然后比对人审和机审。不一致的地方，找第三个专家裁决。这就是盲测。做不了几千条就做几百条，做不了几百条就做五十条。有数据比没数据强一万倍。

第四，监控漂移，不监控绝对值。

法规变了、业务规则变了、数据分布变了，Agent 的能力会漂移。今天上线漏审率 5%，三个月后可能变成 15%，因为新类型的合同出现了。

所以不能上线测一次就完了。每个月抽一批最新的案例跑核心指标。这叫持续评估。

这四件事，没有一个需要 SWE-Bench。没有一个需要标准测试集。但它们需要你承认一个事实：你的 Agent 没有标准答案，只有相对改进。 而相对改进，是可以被量化的。

这一节是我跟前沿 Agent 世界最大的分歧，他们追求绝对数字，我追求相对改进。因为在脏世界里，相对改进就是一切。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】