企业官网建设流程全解析

上周我帮团队处理一个特别头疼的问题：同一个 LLM 接口，有人拿它写出像模像样的周报，有人拿它输出完全没法看的表格，还有人在关键数字上被模型“温柔地欺骗”了。后来我把项目思路收敛到一个方向上：不要把大模型当成“万能生成器”，而是把它放进一套带质检、带流程、带验收标准的执行骨架里。这个骨架，社区里叫 Agent Harness。OpenWorkBuddy 就是围绕这个思路做的一个典型拆解对象——它想解决的问题很明确：怎么把一次 LLM 调用，变成一份可交付、可追踪、可回归验收的办公产物。这篇文章我会从原理讲到落地，把 Harness 的设计思路、完整流水线、容错手段和踩坑记录都摊开聊一遍。

1. 先搞清楚：Agent Harness 和裸调 LLM 到底差在哪

1.1 裸调 LLM 有哪些说不出口的痛

先说个最日常的场景。你让大模型“帮我写一份第三季度的竞品分析”，它确实会写，但你拿到手的往往是一堆不可预测的东西：格式一会儿是 Markdown 表格，一会儿是分点罗列；价格数据看着合理，实际可能有一半是编的；你想让它只输出 5 个竞品，它心情好给你 8 个，心情不好给你 3 个。这不是模型笨，而是你根本没有给它一个可执行的“作业边界”。

裸调 LLM 的问题集中在三件事上：不可控、不可测、不可复用。不可控是指输出结构飘忽不定，字段缺失、类型混乱是家常便饭；不可测是指没有校验手段，你只能肉眼盯着一份长文本找毛病；不可复用更致命，同样的输入换一个模型、换一个温度参数，跑出来的结果可能完全对不上。对聊天场景这些都能忍，但一旦输出物要进企业流程、要归档、要发出去，这些问题就是事故。

还有一个隐藏痛点：你没法回溯“这份报告为什么这么写”。模型给你一个结论，但它的依据是什么、中间推了几步、哪里可能不可靠，黑盒状态什么都查不到。办公场景里，领导问一句“这个数据怎么来的”，你答不上来，这个产物就没法验收。

1.2 Harness 不是框架，是一条带质检的生产线

“Harness”这个词本身有两个含义：一个是马具/线束，一个是软件工程里的测试夹具。Agent Harness 取的其实是后者的意思——它不是帮你调模型的框架，而是给 Agent 套上一整套工程约束：定义输入输出、管理工具调用、接管执行流程、在输出之后做自动检查和修正。

可以这么类比：裸调 LLM 是直接让一个新来的实习生去给客户出正式报告；Agent Harness 是给这个实习生配上工位、模板、SOP、以及一个专门的质检员。实习生该动脑的地方照旧动脑，但每一步都有章可循，最终交付物要过质检才能出门。

在 OpenWorkBuddy 这类项目里，Harness 通常不是一个几百 MB 的重型框架，而是一组可组合的组件集合：任务规格（Job Spec）、执行器（Runner）、检查器（Checker）、工具集（Tools）、导出器（Exporter）。模型本身只是流水线里的一个“计算单元”，而不是整个系统的灵魂。这个姿态上的转变很关键，它直接决定了系统是“能干活”还是“能出活”。

1.3 办公场景为什么尤其需要这种“约束”

办公产物有非常鲜明的特点：格式有规范、内容要负责、过程可追溯。周报、竞品分析、投标摘要、合同比对、费用统计，这些东西不是写出来自嗨的，而是要进邮件、进共享盘、进管理层决策流程的。决策错了，要追责到数据来源；格式乱了，要被合作方打回；逻辑不通，会被同事质疑专业度。

这些要求注定了办公场景不能容忍“自由发挥”。LLM 的自由度必须被约束在合理范围内：字段从哪来、引用怎么标、数字跟哪个数据源对齐、缺失内容怎么处理，都需要在调用之前就以规则形式定好。Agent Harness 的价值恰恰在于，它把这些约束变成代码、变成可执行的检查项，而不是靠“多写点提示词”碰运气。

如果你只是做个聊天机器人、做个临时翻译工具，那裸调 LLM 完全够用。但一旦产物要“验收”，Harness 思维就变成刚需了。

2. 拆开 OpenWorkBuddy：四个核心设计决策

2.1 产物优先：先定义验收标准，再设计 Prompt

OpenWorkBuddy 给我最大的启发，是它把“产物优先（Artifact-First）”放在了整个架构的第一位。传统做法是先把 Prompt 写漂亮，希望模型输出理想结构；Artifact-First 则完全反过来——先把交付物的“验收单”写清楚，再根据验收单反推任务怎么拆、Prompt 怎么设计、工具怎么调。

举个例子。你要生成一份竞品分析 Excel，先写清楚验收单：必须有产品名、所属品类、定价区间、核心优势、主要短板、信息来源这几个字段，每个字段都有类型约束。然后你用这个 Schema 去约束模型的输出，模型吐出来的内容先经过解析，解析失败的直接进修复流程，绝不放行。

from pydantic import BaseModel, Field, HttpUrl class CompetitorItem(BaseModel): product_name: str category: str market: str pricing: str = "" strengths: list[str] = Field(default_factory=list) weaknesses: list[str] = Field(default_factory=list) sources: list[HttpUrl] = Field(default_factory=list) class CompetitorReport(BaseModel): generated_at: str data_window: str items: list[CompetitorItem]

这段代码看起来简单，但它是整个流水线的锚点。Prompt 写得再花哨，最后都要落回这个结构上。字段名不匹配、来源缺失、列表为空，都会在解析层被拦截下来。我在实际项目里体会特别深：只要 Schema 一旦定死，后面几乎不会再出现“产出格式随机漂移”这类问题。

2.2 结构化中间态：把“思考过程”变成可检查的数据

很多 Agent 项目只关心最终结果，中间过程一概不管。OpenWorkBuddy 的思路是把任务拆成多个阶段，每个阶段都有明确的输入和输出 Schema，也就是它强调的结构化中间态。

比如“生成竞品报告”这个任务，可以拆成资料采集、事实抽取、初稿生成、格式转换四个阶段。资料采集阶段输出的是“一批网页摘要和检索结果”；事实抽取阶段输出的是“结构化事实列表”；初稿生成阶段才真正调用大模型把事实组织成段落。每一阶段的结果都落成数据对象，可以检查、可以审计、甚至可以被人中途手工修正。

这样做最直接的好处是：你能知道错在哪一步。如果最终报告里价格数据错了，你可以顺着链路往回查，是采集阶段没拿到价格信息，还是抽取阶段把“预估价格”当成了“官方价格”，还是生成阶段把数字写串了。裸调 LLM 的情况下，这种定位根本不可能。

另外，结构化中间态让任务具备断点续跑和人工介入的能力。某个阶段的输出明显不可信，可以直接丢弃重跑该阶段，不需要整条流水线从头再来。对于动辄几分钟的长任务来说，这个省下来的成本相当可观。

2.3 Runnable 和 PostRun 分离：执行完不算完

OpenWorkBuddy 在设计上把执行环节和验收环节彻底拆开，我把它理解为 Runnable 与 PostRun 两个阶段。Runnable 阶段负责“把活干完”，PostRun 阶段负责“把活验好”。这个分离极其重要，它借鉴了软件工程里 CI 流水线的思想：构建之后一定要测试，测试不通过就是不发布，没有任何商量余地。

class BuddyPipeline: def __init__(self, spec, model_client, tools, checkers, exporter): self.spec = spec self.model_client = model_client self.tools = tools self.checkers = checkers self.exporter = exporter def run(self): ctx = self.bootstrap_context() for step in self.spec.steps: ctx = step(ctx, self.model_client, self.tools) self.checkpoint(ctx) artifact = self.assemble_artifact(ctx) for checker in self.checkers: checker.verify(artifact) # 验收不过直接抛出异常 return self.exporter.export(artifact)

上面这段伪代码展示了核心套路：先执行一系列步骤，拿到组装好的对象，然后跑所有检查器，最后才导出。检查器可以有很多个，比如必填字段检查、来源引用检查、日期一致性检查、模型打分评估、以及“和上一次结果做回归比对”的稳定性检查。任何一个检查不通过，产物都不会进入导出环节，而是回到修复回路里继续加工。

这种设计在工程心理学上也很有讲究：人为失误的高发区，往往不是“写不出来”，而是“没检查就交付”。把检查变成一道不可绕过的闸门，系统整体的交付质量会上一个台阶。

2.4 轻量治具体系：不绑框架，所有能力可替换

现在市面上很多 Agent 框架喜欢搞“全家桶”：自带向量库、自带规划器、自带一组默认工具、甚至自带 UI。OpenWorkBuddy 的取向恰好相反，它把每个能力都设计成可替换的“治具”：模型可以换成 OpenAI 兼容接口，也可以换成本地部署的小模型（比如 GGUF 格式的量化模型）；检索可以用向量数据库，也可以直接对接公司内部的文档系统；导出器可以从 Markdown 换成 docx、xlsx、PDF。

这种轻量组合最大的好处，是降低了迁移成本和调试难度。模型断供了，换一个 Provider 就行；某个工具不好用，单独换掉它；公司内部有自研的权限系统，就在工具层接一层封装。它不逼你做技术选型的“一锤子买卖”。

我在实际落地时很看重这一点。因为 LLM 领域的工具更新太快，年初选的“最佳方案”，年底可能就变得不再划算。如果一个 Agent 项目的核心逻辑和某个重框架深度捆绑，后续每一次演进都会非常痛苦。OpenWorkBuddy 这种“核心流程 + 可插拔组件”的组合，反而在长时间维护里更省心。

3. 从 LLM 调用到可验收办公产物的完整流水线

3.1 把“验收单”写成代码：产物的 Schema 设计

前面说了 Artifact-First 理念，具体落地就是设计产物 Schema。这一步做得好不好，直接决定整个流水线顺不顺。我总结了不少经验，其中三条最关键。

第一，区分“业务字段”和“审计字段”。业务字段是用户真正关心的内容，比如产品名、价格、评论；审计字段是用于追溯的元信息，比如生成时间、数据窗口、资料链接、置信度。很多人设计 Schema 时只写业务字段，结果产物出了问题没法溯源。我习惯让每个结构化对象都带generated_at、data_window、sources这类字段，它们不占用太多 token，但价值巨大。

第二，不要硬让模型输出所有字段。有的字段可能确实采集不到，与其逼模型编造，不如允许空值并配套一个“缺失原因”字段。比如价格信息没找到，就写pricing=None，同时pricing_note="官网未公开，仅找到第三方报价页"。这样既诚实又便于后续人工补录。

第三，嵌套不要太深。模型对“三层以上的嵌套 JSON”很容易出错，尤其是在函数调用参数里。尽量把 Schema 拍扁，能用扁平的 list 就不用深层的 dict。别看这是细节，实际运行中能把解析失败率降一个量级。对，provider 拒绝工具请求的很多原因，就是因为参数 Schema 写得太复杂。

3.2 编排流水线：从资料采买、抽取到成稿的五段式流程

基于 Schema，OpenWorkBuddy 推荐把办公任务拆成五个标准步骤：任务解析、资料采集、事实抽取、内容生成、校验修正。这套流程几乎适配所有“分析/报告/总结”类任务。

任务解析阶段，模型根据 Job Spec 把用户需求转成一份内部任务清单，明确要做什么、不做什么、输出边界在哪。资料采集阶段，通过检索工具抓取需要的原始材料，保存为带来源标注的检索片段。事实抽取阶段，从原始材料里抽取结构化事实，这一步已经开始受 Schema 约束。内容生成阶段，大模型基于事实列表生成正式内容，而不是凭空发挥。最后是校验修正阶段，跑完前文说的检查器，不过就回到前面的阶段打回去重改。

我把这个流水线比作“做饭流水线”：买菜（采集）、洗切（抽取）、烹饪（生成）、试菜（校验）。每一步都有专用工具和标准，而不是让一个厨师从买菜一路干到摆盘。LLM 是厨师，但你不能让厨师自己买菜、自己洗菜、自己算热量，那样他一定会偷懒或者出错。

3.3 五层验收机制，把人工复核压到最后一档

OpenWorkBuddy 的验收机制是我最欣赏的部分，它把验收拆成了五个递进层次，每一层解决一类问题。

• 格式层：检查产物是否能被 Schema 正确解析，字段类型、必填项、枚举值是否符合预期。
• 内容层：检查内容的语义质量，可以用“LLM as Judge”的方式让另一个大模型按打分卡评估内容完整性、准确性。
• 逻辑层：检查业务规则，比如日期先后顺序、金额是否匹配公式、竞品名单是否有重复、总数是否等于明细之和。
• 引用层：检查每个事实字段是否都带来源，来源是否真实存在、是否真的支持该结论。
• 回归层：对同一批输入跑两次，比较结果差异，差异过大会触发告警，说明流程稳定性存在问题。

五层检查不是每层都要跑满，具体可以按任务类型裁剪。比如一次性的头脑风暴产物，跑格式层和内容层就够了；但财务统计类产物，逻辑层和引用层必须全开。这个设计思路的本质是“机器能兜的底绝不让老板承担”，人工复核只保留在最后一道判断题——判断机器给出的结论是否放行，而不是从零开始逐行找错。

3.4 导出环节：把结构化对象变成 docx、xlsx、PDF

办公产物最终要落在具体文件格式上，这一步 OpenWorkBuddy 的实践是只做模板填充，不做模型生成。也就是说，导出器是一个纯代码模块，负责把结构化数据渲染进预定义的模板，比如用 python-docx 生成报告文档、用 openpyxl 生成数据表格、用 python-pptx 生成演示文稿、用 Markdown 加转换工具生成 PDF。

这个决策避开了最大的坑：大模型直出 Office 文件。模型生成的 docx 往往又脏又乱，合并单元格错位、样式漂移、页脚丢失，一个人工修复的成本远比自动生成高。把 LLM 限定在“生成结构化数据”这一层，而格式渲染交给确定性代码，产物稳定性和维护成本会好得多。

[TOC]

4. 容错与控制：一个可靠 Agent 系统的工程实践

4.1 重试不是唯一手段：降级、回退与止损的搭配

很多人一谈容错就想到“重试几次”，但实际工程里，重试只是最后的手段，而且必须带着策略重试，不是无脑重跑。OpenWorkBuddy 的容错策略我归纳成三条链路：降级、回退、止损。

降级是把一个不那么强的方案顶上。比如首选模型返回格式频繁不达标，立即降级到另一套更稳、但可能更贵的模型；或者把复杂工具调用降级成普通文本输出，让模型先生成 JSON 文本，再由代码解析，而不是直接用函数调用。工具调用失败时，这个降级路径非常常用。

回退是放弃 AI 方案，走规则方案。比如大模型抽取价格信息反复失败，那就回退到“从结构化数据源读取 + 正则抽取 + 人工确认”的保守路径。保住“能交付”的底线，比追求“全 AI 自动化”更重要。

止损更关键：给整个流水线设定成本上限和时间上限。比如跑批任务预算 3 美元，跑了 10 分钟还没完成，就触发终止。很多 agent 翻车都是“无限重试、无限扣费”，这是生产和实验场景最大的区别。生产线上的机器坏了不能反复强行启动，要有安全开关。

4.2 校验回路里的自我修正：让 Agent 自己补作业

容错还体现在“修”而不是“抛”。OpenWorkBuddy 里有一个很实用的设计：当校验器发现某个字段缺失或内容不准确，校验器不只返回“失败”，还会返回结构化的修正建议，然后让执行器带着这些建议重新生成。

比如一份竞品分析里，某条记录没有sources，修正提示会明确说“该记录缺少来源，请返回事实抽取阶段，针对产品名重新检索至少两个来源”。这比笼统地说“格式错误，请重新生成”要高效得多，因为它把 Agent 的注意力精准引导到了问题部位。我做过的几次对比测试，带修正提示的重试成功率通常在 85% 以上，而笼统重试只有 50% 上下。

这种自我修正回路也避免了“检查器把问题甩给人工”的结局。人只处理那些机器反复修了几次仍然搞不定的少数疑难杂症。

4.3 知识库会中毒：Agent 推理时的记忆污染防御

大家在热词里看到过 AgentPoison 这类研究，核心思路是通过污染 Agent 的记忆库或检索知识库，让智能体在被诱导的情况下做出误判——比如让一个杀毒 Agent 把恶意软件标记成正常程序。办公场景同样存在这类威胁，而且往往不是恶意攻击，而是“资料污染”：检索库里混入了过期数据、错误观点或者未经验证的网络内容，Agent 把这些当成了事实来源。

OpenWorkBuddy 的防御姿态有三层。第一层是来源白名单，只有经过审核的数据源才允许进入检索范围，外部网页默认是低可信来源；第二层是引用强制，任何进入产物的结论必须附带来源，如果一个结论找不到来源，宁可标“未验证”也不写进正文；第三层是定期审计，对知识库里的关键条目做随机抽查，看 embedding 结果和原文是否一致、看是否有异常改写的内容混入。

这套防线不复杂，但能挡住绝大多数“莫名其妙”的错误结论。我见过不少 Agent 项目在这上面吃过亏：给模型配了一个公开网页爬虫抓来的知识库，结果把几年前已经失效的竞品报价写进了正式报告，就是因为没有来源管控。

4.4 全链路可观测：Token、耗时、成本和审计日志一起抓

最后一条工程实践是可观测性。OpenWorkBuddy 给每个任务生成一个 Trace 对象，里面记录了每一步的耗时、模型调用次数、Token 消耗、工具返回状态、校验结果。任务做完之后，不仅输出产物，还输出一张“体检表”。

这部分对于“验收”相当重要：办公产物的验收不只看内容，还要看过程是否合规。比如一个季度竞品报告，领导会问“价格数据什么时候采的”“有没有比对官方定价”。如果系统能直接给出采集时间、来源链接、校验记录，这件事就从“信不信你的报告”变成了“核对一下审计日志”，信任成本大幅降低。

成本核算也一样。规定每次跑批预算上限后，用 Trace 统计实际支出，月底汇总到一张表里，哪个任务烧钱、哪个模型性价比低一目了然。没有这套记录，你根本无法判断一次 Agent 调用“值不值”。

5. 实操实录：用 OpenWorkBuddy 生成一份可验收的竞品分析

5.1 场景与 Harness 配置

选一个真实场景来完整走一遍：生成一份 SaaS 领域竞品价格分析表格，目标文件是 xlsx，表格包含产品名、适用规模、报价模式、月费区间、核心优势、不足、数据来源共 7 列。

Harness 配置如下：模型使用 OpenAI 兼容接口的通用模型，温度设 0.2，关闭流式输出；工具集配一个网页搜索工具和一个指定官网解析工具；表格模板预设在 openpyxl 里，包含表头、列宽、冻结窗格和条件样式；检查器开了三项：必填字段检查、来源检查、价格区间逻辑检查（低价必须小于等于高价）。

任务最终交付物定义为一个CompetitorReport对象，这个对象在前面代码里已经展示过了。写清楚 Job Spec 是第一步，我一般用一份 YAML 来描述任务目标、交付格式、允许工具和限制条件。这相当于给整个智能体立规章制度。

5.2 核心代码：Runner、校验器和导出器怎么配合

核心流程跑起来确实是三步走：Runner 执行、Checker 验收、Exporter 导出。Runner 部分前面已经写过简化版，这里展示一个关键的校验器实现，以及工具调用载荷的例子。

class ReferenceChecker: def verify(self, artifact): items_without_sources = [ item.product_name for item in artifact.items if not item.sources ] if items_without_sources: raise CheckError(f"以下条目缺少来源引用: {items_without_sources}")

工具调用载荷长这样，结构化输出到arguments，由工具层执行并返回结果：

{ "tool": "web_search", "arguments": { "query": "竞品A 2024 官方定价 月费", "max_results": 8, "site_filter": ["official_website", "documentation"] } }

导出器则纯粹做渲染。openpyxl 里按列写入数据，对价格区间列做“低-高”格式拆分，再顺手把来源链接写成一个单独的“数据来源”工作表。整个过程没有任何模型参与格式判断，稳定得很。

5.3 验收清单与实际跑批结果

我实际跑过一版，记录了几组值得参考的数字。第一轮跑了 8 分 12 秒，原因是检索工具在网站过滤上反复产生无效点击；模型调用 token 花了 4.6 万，费用差不多 1.2 元，但格式错误率偏高。调了参数之后，把检索工具的最大返回数从 8 降到 5，温度从 0.7 改到 0.2，并且加了一条“如果官网没有明确刊价，允许标注 None 并附说明”的规则，第二轮耗时降到 2 分 40 秒，token 降到 1.8 万，字段完整率到了 96%，来源覆盖率 91%。

人工复核抽了 10 条记录，发现 1 处问题：某个竞品的价格信息来自第三方报价站，实际官网已经调价，数据时效性不够。于是我又加了一个DataFreshnessChecker，检查data_window是否在 30 天以内，超过则要求重新采集。第三轮跑下来就没再发现类似问题。

这组数据说明一件事：Agent 系统的质量不是靠一次调优，而是靠“检查器发现问题、规则补上问题”这样一圈圈迭代出来的。

6. 常见问题与排查技巧实录

6.1 输出非法 JSON / 长文被截断

这是所有 LLM 应用第一个要碰到的坎。症状是解析器反复报错，或者文档生成到一半戛然而止。常规解法：调低 temperature、打开 JSON 模式或函数调用模式、禁止思维链以文本形式流出、限制长输出分块生成。还有一个冷门技巧——让模型“先输出一个括号{，再继续输出”，能把很多解析失败提前规避掉。

截断问题的根治方案是拆任务：不要指望一次调用生成三千字的完整报告，而是让每个 Schema 字段分别生成，比如先让模型抽取事实，再按段落逐一生成。这相当于把一次超长请求拆成多次短请求，成功率会显著提升。

6.2 幻觉数据混进最终产物

幻觉是办公场景绝对不能容忍的问题。我的做法是双保险：第一，强制所有事实字段带来源；没有来源的字段一律标None或“未验证”，绝不硬编；第二，在内容层检查器里用另一个模型做“事实一致性抽检”，把产物中的数字、日期、专有名词和原始检索片段做比对，发现对不上的就标记并打回修正。

实际跑下来，这种“AI 查 AI”的方案能过滤掉大部分明显幻觉，但要注意：抽检模型的可靠性依赖明确的比对指令和低温度，最好固定用同一个模型版本，避免“裁判”本身波动。

6.3 Provider 拒绝工具调用请求

热词里有句报错原文：“LLM request failed: provider rejected the request schema or tool payload.”遇到这个问题，十有八九是工具参数 Schema 写得太复杂或者格式不对。模型在函数调用时对参数结构有一些隐性约束：嵌套过深、字段过多、描述太长、枚举值太多，都容易触发拒绝。

解法是给工具做“减肥”：把工具描述精简到一句话，参数类型用string、number、array这类基础类型，嵌套超过两层的拆成扁平参数，再用代码在工具层去组合。我这里有一个铁律：工具能收 3 个参数，绝对不写 5 个。

6.4 表格与文档格式不稳定

如果有人试图让大模型直接输出格式化后的 Office 文件，大概率会踩这个坑。症状是单元格合并时对时错、字体样式每天都不同、某些行莫名其妙消失。我的建议非常直接：放弃“LLM 直出文档”方案，改成“LLM 出数据，代码出文件”。所有固定版式交给模板代码，LLM 只负责填充结构化内容，前后一致性立刻稳定。如果必须输出 PDF，先用 Markdown 或 HTML 生成再由转换工具处理，不要寄希望于模型理解复杂的页面布局。

6.5 Token 成本与整体耗时失控

办公自动化的成本问题比想象中严重，尤其是一开始只写功能、不做预算控制的时候。几轮乱重试下来，一次跑批费用能翻十几倍。我建议所有任务都设置两层预算：一是单次任务 token 上限，在 Runner 里累计统计，超了直接终止；二是重试次数上限，默认 2 次，超过就转人工。另外，对相似度高的历史请求做缓存，能在成本上省下不少，尤其是竞品分析这种可能反复跑同口径的任务。

下面按我自己的经验整理一份速查表，排查时照着对就行：

7. Harness 和 LangChain/CrewAI 这类框架该怎么选

7.1 核心差异：约束力、透明度和学习成本

很多人会问：既然有 LangChain、CrewAI 这么成熟的框架，为什么还要用 OpenWorkBuddy 这种轻量 Harness？我的理解是，它们解决的问题根本不一样。LangChain 和 CrewAI 更像“乐高积木库”，给了你大量的组件和编排方式，但并不会强制约束产物结构；你用它们能做很灵活的探索，但要推到生产级“验收”，还得自己在外面再套一层检测机制。

OpenWorkBuddy 这类 Harness 刚好处在相反的一端：它强制你定义 Schema、强制你走检查器、强制你把执行和验收分开。这种约束力在两种人眼里价值不同——对于做探索原型，约束是麻烦；对于做正式交付，约束是保护。

透明度和可维护性的区别更明显。LangChain 的抽象层数多，出问题时要顺着一层层调用栈往里查；Harness 的逻辑则很直白，一个 Runner 跑步骤、一组 Checker 做检查，出了问题一眼就能定位。学习成本上，前者要学大量概念和 API，后者更像“写普通 Python 函数”，几天就能上手。

7.2 我给团队的选型建议

如果要生成正式办公产物（周报、分析报告、报价单、标书初稿），我会优先选 Harness 思路。因为这类需求最痛的就是“验收”，而 Harness 从一开始就把验收嵌进了流程，稳定性是骨架级的。如果要做聊天机器人、开放域问答、多角色模拟、探索型数据分析，LangChain/CrewAI 这类框架体验更好，开发速度快、生态丰富，不需要太纠结产物规范。

还有一个中型团队推荐的折中方案：核心链路用 Harness 约束，外围的探索工具、知识库管理、多 Agent 协作用成熟框架。我自己就是这么落地的——OpenWorkBuddy 负责出正式产物，CrewAI 负责一些需要“多角色头脑风暴”的前期分析，两边通过一个标准 Schema 对接。这样既保住了交付质量，也没放弃探索灵活性。

8. 写在最后：几条踩坑之后的个人体会

这套东西实际推下来，我最深的体会是：Agent Harness 不会让模型变得“更聪明”，但会让系统变得“更可信”。办公产物真正缺的从来不是妙笔生花，而是“出了问题找得到原因、说过的话站得住脚、交付的格式能直接进流程”。OpenWorkBuddy 提供的不是一套神级 Agent，而是一套让 LLM 收着干的规矩——这恰恰是生产环境里最重要的东西。

最后再分享一个小技巧：别一上来就搞一套大而全的 Harness。从我自己的经历看，先挑一个最痛、最重复的办公任务（比如每周的竞品周报），设计好 Schema 和两类检查器（必填字段 + 来源引用），跑出一版能验收的产物，再慢慢把检索、重试、审计、成本控制一个个加进去。这套路子看着慢，但每一步都在往“机器能兜底、人工只确认”的方向走，过程中积累的每个 Checker，最后都会变成你团队的固定资产。