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).pdf2018 年扫的有的页面是斜的有的签名和标注糊得看不清。你的反馈是业务主管下午开会时说这个不对但我得再确认下然后下周才给你个几百字的回复。没有 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 是解法问题和解法之间从来不是 11 映射。但你必须先看清这五堵墙才能理解为什么后面要那样设计。第一堵墙数据是脏的而且你低估了有多脏。你以为是几百份 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 ResultAgent层面无非也就是判断下哪些内容重量然后拼接在Prompt的最后。但你的世界不是。你的一份招标文件 300 页法规附件 50 份历史中标案例 2000 个加起来轻松破百万 token哪个都不能忽略哪个都十分重要模型在里面跟瞎子摸象一样。第四堵墙业务逻辑本身就是模糊的。理论上法规条款 A 对应报告段落 B逐条匹配就行。实际上法规写的是合理期限业务方问你合理是几天。法规说应当设置明显的安全警示标志业务方问你什么叫明显。每个公司内部的制度和现实犯规又有冲突内部制度也没有完整的数字化文件给你。这些模糊性不是 bug是业务逻辑本身。法律就是这么写的因为它必须留解释空间。你的 Agent 不能假装规则是清晰的因为规则本来就不清晰。这一点 Coding Agent 永远不会遇到代码不模糊要么编译过要么编译不过。第五堵墙用户既要又要还要。要准漏一条就是事故。要快等 30 秒就开始催。要便宜token 预算砍了一半还要砍。要简单不写 prompt不给示例甚至说不清自己要什么你就按我们平时的标准来。你做的不是 Agent。你是在四个互相矛盾的需求之间找一条能走的路。这五堵墙不是某个项目的特例。是每一个做企业 Agent 的工程师迟早会撞上的。解法不在模型里在 Agent 系统工程里换模型解决不了这五堵墙。下一代开源模型再便宜业务逻辑一复杂照样跑偏。Claude 再强价格摆在那里客户每月预算就 8000 块。下一代闭源模型出来也不一定能替业务方把“明显”这个词定义清楚更不能替你管理上下文窗口。解决这些问题的是模型之外的整套系统工程。它至少包含四种不同性质的层数据工程脏数据怎么变成可查询、可审计的资产。这一层跟 LLM 几乎无关。HarnessAgent 跑起来之后上下文怎么调度、工具怎么编排、流程怎么控制、错误怎么兜底。这一层才是严格意义上的 HarnessClaude 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 里写请判断合同中的违约金条款是否合理。这会出三个事不一致。同一份合同跑两次可能给出不同结论。LLM 哪怕设了 temperature0对合理这种主观词的判断跨次调用、跨模型版本都不稳定。不可解释。业务方问为什么你判断这条不合理LLM 给你一段含糊的基于行业惯例和合同上下文。业务方一脸懵你也一脸懵。不可协商。业务方说你这个判断标准太严了放宽一点你怎么改改 prompt改完哪里变松了哪里变严了谁也说不清。业务方真正需要的不是聪明的判断是可讨论的判断。正确的做法是把模糊翻译成显式的判断标准对每个模糊条款离线用 LLM 生成 3-5 个具体化的判断标准。比如违约金合理翻译成违约金不超过合同金额的 30%、违约金计算方式明确写出、违约金有触发条件且条件可量化等等。这些标准跟业务方一起 review改到双方都认可。这一步业务方必须在场不是工程师拍脑袋。审查时Agent 不判断是否合理只判断是否满足这些显式标准。标准本身是配置化的、可版本化的、可追溯的业务方看到结果不对改的是标准不是 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%免费】