审100份文档和审1份水平完全一样传统AI审查系统不会学习。而我们做的这个审查系统审得越多越聪明。上个月我们交付了一个企业文档智能审查模块。客户把施工设计说明扔进去几分钟后就能拿到一份结构化的审查报告——设计规范引用问题标红、专业间冲突列清单、合规风险点给等级。更关键的是用户纠正过的错误系统下一次不会再犯。审得越多和客户的审查标准对齐得越准。我们没有自己整 harness 框架也没有自己再去实现一套自进化逻辑。那如何实现这一切呢 hacker news 上有句话说的非常贴切Claude Code Is All You Need 。 有claude code 就够了。文档审查为什么这么难先来说下为何自动审查这个事情在传统的模式下难做做过企业项目的都懂文档审查是个看起来简单、做起来吐血的需求。合同条款动不动几十页法务逐条核对要花一整天运维手册上千条规程新来的工程师三个月都看不完标书里的技术参数密密麻麻漏一个关键项就可能废标。传统做法无非两条路规则引擎写死校验逻辑但规则一多维护成本比开发还高人工审查靠专家逐条核对效率低不说不同专家的判断标准还不统一。中间态方案也试过。Dify 拖拽工作流审到第三页就忘了第一页的内容做的知识库检索召回的相关条款经常跑偏LangChain 搭链式调用debug 的时间比写代码还长。这些方案的共同问题是什么它们都是静态系统。规则写死就不会变流程拖好就不会改知识灌进去就永远是那批文档。审一百份文档和审一份系统本身毫无成长——这不是符合现在技术发展他是缺智能本身。“Agent Harness这个概念我们在之前的文章里详细拆解过。简单说Agent 是模型本身不是框架、不是 Prompt Chain、不是拖拽工作流。Harness 是运行这个 Agent 的环境”——给它工具、给它知识、给它观察能力、给它行动接口、给它权限边界。Harness 做得好Agent 就聪明。Harness 做得差再好的模型也发挥不出来。问题就在于做一个好的、稳定的 Harness 对于团队的要求很高。因为模型的能力是在持续变化增强的所以 Harness 也必须要动态调整以适配 LLM 更好的协作。所以对于做应用的团队来说在理解这一切的基础上找一个相对成熟且持续迭代的基础智能体在这个基础上去构建自己的应用在项目的前期阶段是一个理性的选择。为什么 claude agent 就够了在做这个项目之前我们已经深度使用过 Claude Code。用起来最直观的感受是——它懂你。你改了一个函数签名它自动去更新所有调用方你描述一个 bug它先翻日志再动手修到了某个节点它主动停下来问你确认而不是闷头往下猜。这种懂不来自更大的模型而来自它底层的 Agent Harness。上下文管理不是简单的滑动窗口——它知道哪些信息该压缩、哪些该保留、什么时候该召回。Skill 引擎让它在不同场景加载不同行为——写代码时是一个专家做 code review 时是另一个。MCP 引擎把它接到外部工具和数据源上不是孤岛里的一个聊天窗口。ask_user 交互组件让它在模糊地带主动要澄清而不是硬猜。这四个组件只是 Claude Code Harness 的冰山一角但已经足以说明问题——Claude Code 不是一个更强的 ChatGPT它是一个真正能让 Agent 干活的环境。而我们要做的就是把这个环境的核心能力应用到企业场景里去。但 Claude Code 是一个终端工具不能直接嵌入企业系统。我们需要的是一个能提供同样 Harness 质量的 Agent 平台——让它成为企业流程中的一个数字员工而不是开发者手边的一个命令行工具。这里的选择很多可以是Claude Agent SDK, 也可以是OpenAI Agents SDK还可以是其他提供 harness 基础设施的框架、或者项目或者组件。 我们在这里选择一个带管理后台的 agent 平台并在我们的服务器上搭建了这个 Agent 服务平台它继承了 Claude Code Harness 的核心理念但面向企业场景做了适配Session 管理——每个审查任务创建一个独立的 Session上下文互不污染。一份文档的审查不会影响到另一份就像每个任务分配了独立的大脑。WebSocket 实时通信——审查过程不是提交任务→等结果的黑盒。Agent 的进度通过 WebSocket 实时推送到前端正在下载文档、正在加载规范、已完成第三章审查……用户看到的是一个在干活的 Agent不是一个转圈圈的加载动画。Skill 行为定义——每个审查场景对应一个 Skill。审查施工设计说明的 Skill 定义了审查流程、评判规则、输出格式、工具使用约定。用户发起审查时触发 Agent 加载对应的 Skill就知道自己这次是施工设计审查专家还是运维手册审查专家。工具集——Agent 可以调用execute_code执行 Python 脚本下载文件、落盘用read工具按审查条目语义检索文档中的相关段落用 LLM 的大脑做规范判断。确定性的操作下载、解析交给工具不确定的判断合规性评估交给模型。这些能力合在一起就是一个会干活的数字员工。架构设计三层 一条实时通道不少所谓的AI 审查系统本质是套壳 ChatGPT——前端加个上传按钮后端调个 APIPrompt 里写几句请帮我审查。结果可想而知不稳定、不可控、不可信。我们的设计思路不一样不是让 LLM 审查文档而是让一个完整的 Agent 来审查文档。区别在于——Agent 有工具、有知识、有流程、能自我纠错。系统分为三层外加一条贯穿始终的 WebSocket 实时通道。第一层前端。用户上传文档、选择审查维度、启动审查、实时查看进度和结构化报告。技术栈 Vue 3 TypeScript聚焦交互体验——重点是审查过程中的实时反馈而不是一个提交后干等的黑盒。第二层Agent 平台。系统的核心。提供 Session 隔离、WebSocket 通信、工具执行环境、Skill 加载。这层的核心认知是**Agent 不是在调 API而是在执行多步骤任务**——它自己决定先下载什么、按什么条目审查、何时检索规范、如何输出结果。这是 Agent 和单次 LLM 调用的本质区别。第三层后端 OSS 数据库。OSS 是文件的唯一事实源数据库只存文件引用不存在双写不一致的问题。后端通过 manifest 机制为 Agent 提供任务上下文和文件流全部通过 token 鉴权。前端从 WebSocket 收到审查结果后写回数据库Agent 不需要回调 HTTP。整个架构的设计原则一句话确定性的操作交给代码不确定的判断交给 Agent。文件上传下载、格式转换——确定的后端处理。规范条款解读、合规性判断、模糊地带权衡——不确定的交给 Agent 的大脑。审查模块的框架如下图所示反馈闭环系统越用越聪明的秘密前面说的三层架构解决了能审的问题。但真正让这套系统区别于传统方案的是它能越审越准。机制本身不复杂用户看到审查结果反馈审查的判定错误并给出理由、漏审了某个问题。这些标注不会存进数据库吃灰而是在下一次审查时作为上下文喂给 Agent。举个例子。第一次审某份施工设计说明时Agent 判定缺少抗震设计参数引用为严重问题。但用户标注根据项目实际情况该建筑高度不足 24 米按规范可不强制引用。这个纠正被记录下来。下一次再遇到类似情况Agent 的上下文里就有了这条经验——它会先检查建筑高度再下判断而不是机械地套用规范条文。这跟人带新人的逻辑是一样的。不是一次性把所有规则灌进去而是在实战中不断纠正、不断对齐。审十份文档之后Agent 对你客户的审查标准的理解和刚部署时已经是两个水平。这个反馈数据本身就是客户的竞争壁垒。同一套系统部署给 A 客户和 B 客户三个月后它们是两个不同的审查专家。因为各自积累的反馈数据不同。系统本身成了一个活的、持续增值的资产而不是一个买来就折旧的工具。这也是为什么我们说越用越聪明了。几个关键设计决策回顾这个项目的设计过程有几个决策事后证明是对的。Skill 而不是代码不同文档类型需要不同的审查逻辑。施工设计说明关注设计规范引用和专业间一致性运维手册关注操作规范和安全条款设计计算书关注结构参数和公式准确性。我们把每个审查场景定义为一个 Skill 文件。一份 Markdown 格式的配置文件用户触发不同的审查场景 Agent 按需加载 skill, 也就知道自己这次是施工设计审查专家还是运维手册审查专家。新增一个审查场景就是加一个 Skill 文件。业务人员可以直接编辑甚至都不需要开发介入。Session 隔离每个审查一个独立的大脑做过 Agent 开发的人都知道一个坑上下文污染。上一个任务的状态残留在下一个任务里导致判断偏差。我们的做法是每个审查任务分配一个独立的 SessionsessionId 持久化到数据库的审查记录上。一份文档审完Session 就结束不会把上一份文档的内容带到下一份里。就像给每个审查任务分配了一个临时工——任务完成记忆清空。OSS 单一事实源源文件只存在 OSS 上数据库只存一个ossFileKey。后端不存文件副本Agent 也不直接从数据库读文件。这样做的好处很简单不用操心 DB 和 OSS 数据是不是一致的——OSS 就是唯一的文件事实源不存在不一致的可能。Agent 下载文件工具执行模型判断Agent 的工具分工明确execute_code负责确定性操作执行 Python 脚本下载 manifest、源文件和规范包到本地目录read负责按需检索根据审查条目语义检索文档中的相关段落不把整份文档一把塞进上下文LLM brain 负责不确定性判断对照规范条文评估合规性给出判定理由这不是Agent 万能论恰好相反这是承认 Agent 和模型各有擅长把合适的事交给合适的能力。从定制项目 泛化到“通用系统”OpenSpec 上线运行后一个有意思的发现是这个架构的通用性远超预期。最开始我们只做了施工设计说明审查。客户问“运维手册能审吗” 加了一个 Skill能审了。又问“设计计算书能审吗” 再加一个 Skill又能审了。每一次新增场景改的不是代码是 Skill 和 数据库里的规范条文。Agent 的能力边界取决于你给它什么知识、什么工具、什么流程——不是取决于你写了多少代码。企业 Agent 的核心壁垒不是模型、不是框架而是 Harness 的质量。Harness 决定了 Agent 能连接到什么数据、遵守什么流程、在什么边界内行动。模型在快速进化但一个好的 Harness 设计能让你无缝切换模型而不重写系统。这也是为什么我们选择成熟的 Agent 平台而不是自己从零搭建。把 Harness 工程交给最专业的人把精力集中 Harness 中的业务流程建设以及数据知识处理。回到开头那句话大多数 AI 审查系统审 100 份文档和审 1 份水平完全一样。不是因为模型不够大是因为它们缺一个东西——反馈。给系统一个纠正自己的通道它就活了。这不是什么高深的技术是一个设计选择。完整项目地址https://github.com/zhuzhaoyun/OpenSpec项目效果如下图学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%免费】