企业级Agent落地：为什么必须自建Harness？从通用到业务智能体的实践路径

最近帮几家企业做 Agent 落地的时候，我发现一个很普遍的现象：团队一开始都是直接套用市面上现成的通用 Agent，Demo 跑起来确实唬人，可一旦要接真实业务，就各种使不上劲。同样是“帮我查一下客户订单”，通用 Agent 要么去翻了一堆不相干的数据，要么干脆回答“没有权限”，因为它的运行框架根本不是为你的业务流程设计的。这个“运行框架”，圈里现在叫 Harness。

Harness 这个词这几年在 Agent 工程里被反复提起，从 Codex Harness 到 DeepSeek Harness，很多人以为是某个工具或者插件，其实它代表的是一整套控制 Agent 的工程骨架。企业真正需要的，不是再找一个更聪明的通用 Agent，而是建一套自己的 Harness，把通用模型的能力装进自己的业务规则里。这篇文章我就想把这个事讲透：为什么企业需要自己的 Harness，以及从通用 Agent 到业务智能体，这条路到底该怎么走。

我尽量少讲虚的，多讲我在真实落地中踩过的坑、验证过的方法，适合正在做 Agent 选型的技术负责人、负责 AI 落地的架构师，也包括那些刚接触 Agent 开发、想搞懂方向的学习者。

1. 通用 Agent 卡在哪：业务落地的三道坎

1.1 上下文断层：模型不懂你的业务

模型再大，它懂的是“人类的常识”，不是“你们公司的常识”。通用 Agent 默认的世界里，订单就是“订单”，客户就是“客户”，所以当你让它去查订单时，它能想到的只有调用一个模糊的搜索工具，然后从一堆信息里猜。

但真实企业的业务语义要具体得多：客户状态可能是一个枚举字段，0 代表潜在客户，1 代表已签约，2 代表已流失；订单金额可能分含税价和不含税价；库存数据在 ERP 里，物流数据在另一个系统里，两边还没有实时同步。这些信息模型不知道，Prompt 里写一万遍“你是业务专家”也没用，因为模型缺少一个能把这些字段含义、系统关系、数据权限都注入进去的骨架。

这个骨架就是 Harness 的一部分。我经常跟团队打一个比方：通用 Agent 像一个刚入职的高材生，聪明，但不懂你们的流程，Harness 就是那个带他熟悉业务、给他发权限卡、告诉他每一步该找谁的导师。没有这个导师，高材生再聪明，也只能按自己的想象来办事。

1.2 工具不可控：越权与黑盒风险

通用 Agent 在处理复杂任务时，会自己决定调用哪些工具。这个能力听着很爽，到了企业环境里就是个定时炸弹。你会看到它为了查一个交付日期，顺手调用了“发送邮件”工具；为了统计客户数量，直接去拉全库的数据。

问题不只是“调用错了”，而是“根本不可控”。通用 Agent 的模型逻辑是一个黑盒，你没法提前约束它什么能调、什么不能调，也没法准确审计它在一次任务里到底访问了哪些表、调用了哪些系统。业务部门只要碰上两次这种情况，信任就崩了——第一天还夸它聪明，第二天发现它把内部数据发给了无关人员，这个项目基本就寿终正寝了。

真正的企业级 Agent，工具调用必须是白名单制的。Harness 要做的事，就是在 Agent 和业务系统中间加一道闸门，每一个工具调用都必须经过注册、授权、校验、审计四个环节，不能由模型自由发挥。

1.3 没有评估闭环：迭代全凭感觉

通用 Agent 另一个让人头疼的地方是没法评估。今天这个版本回答得不错，明天换了一个底模，同样的 Prompt 可能就答偏了；你改了一个系统提示词，以为优化了，结果其他场景全部回归。没有评估集、没有回归机制，迭代就得靠人工一条条去试，试完心里还是没底。

企业做业务智能体，必须回答三个问题：这次改版比上次好在哪？哪个场景变差了？成本有没有异常上升？这些都要靠 Harness 里的评估与可观测模块来支撑。否则团队很快就会陷入“改一下、试一下、赌一下”的恶性循环，最后谁也不敢动。

2. Harness 到底是什么：给 Agent 套上的业务骨架

2.1 先厘清概念：Agent 和 Harness 不是一回事

很多刚接触 Agent 开发的人会把这两个词搞混。Agent 是那个能感知、决策、行动的主体，它靠大模型做推理，靠工具执行动作。而 Harness 是承载 Agent 的那套运行环境，包括模型怎么接入、上下文怎么构建、工具怎么注册、任务怎么编排、记忆怎么存储、操作怎么审计。

用大白话说，Agent 是发动机，Harness 是整台车的底盘、方向盘和仪表盘。发动机决定这辆车能跑多快，底盘和控制系统决定它能不能安全、稳定地跑到目的地。

最近热起来的 DeepSeek Harness、Codex Harness，本质都是这种思路的某种实现：把模型放进一个可控的“执行框架”里，不让它裸奔。这些项目给行业开了一个好头，但也只是一个参考，因为每个企业的业务语言、数据权限、流程规则完全不同，直接套用别人的 Harness，等于穿了别人的衣服出门，尺码不合适的。

我整理了一个表格，大家感受一下区别：

2.2 一套完整 Harness 的核心组成

根据我自己的实践经验，一套企业级的 Harness 至少要包含七个模块：

• 模型网关：统一接入多个模型，可以是 OpenAI 兼容接口，也可以是本地部署的开源模型，比如 DeepSeek、Qwen、Llama。要支持限流、failover、成本统计。
• 上下文构建器：从业务数据库、知识库、实时系统中拉取并拼装上下文，把零散的业务数据变成模型能看懂的语义化输入。
• 工具注册中心：业务 API、数据库查询、消息发送等能力都封装成标准工具，写清楚工具描述、入参格式、权限等级。
• 编排引擎：支持多步任务编排，比如先查订单，再查库存，最后生成交付方案，也可以配置人工审批节点。
• 记忆存储：包括短期会话记忆和长期业务记忆，比如客户偏好、历史处理进度。
• 安全审计模块：记录每一次调用，包括模型输入、工具调用、返回结果、操作人，敏感数据要脱敏。
• 评估与可观测模块：离线评估集、在线指标、日志追踪，支撑持续迭代。

七个模块听起来多，但真做起来不用一步到位。我给很多企业做规划时，都建议先只做四件事：模型接入、工具注册、上下文构建、审计日志。剩下三个模块等业务量起来以后再补。一上来就求大而全，项目往往死在半路上。

2.3 为什么必须是“自己的”而不是“通用模板”

这是整个话题里我最想强调的一点。很多团队会问：直接用 Dify、Coze、LangGraph 这种开源或者商业框架不行吗？当然行，它们本身就是很好的底座。但“用别人的框架”和“有自己的 Harness”是两回事。

自己的 Harness，核心不是代码，而是沉淀进去的业务资产。比如你精心整理的工具描述字段、你根据自己的风险偏好配置的权限矩阵、你积累了三个月的业务评估集、你针对某些特殊场景写的编排模版——这些东西才是企业的竞争力。开源框架给你的是“毛坯房”，装修成什么样，还是得企业自己来。

更重要的是，业务是在不停变化的。今天你只有一个订单查询场景，明天可能要加一个智能售后，后天又要接新的数据系统。只有沉淀了自己 Harness 的企业，才能快速把这些新能力“插”进去，而不是每次都从零开始重新做一个 Agent。

3. 企业自建 Harness 的实操路线

3.1 先别写代码：把业务场景和责任边界盘清楚

我见过太多失败案例，第一步就摔在“想做一个全能的智能助手”上。全能意味着没有边界，没有边界就意味着没法管控、没法评估，最后就是一个玩具。

正确的做法是选一个高频、低风险、业务收益明显的场景作为起点。我给一家做贸易的公司规划时，选的第一个场景是“智能订单查询与跟单助手”。这个场景的好处有三个：一是订单数据在企业内部系统里，字段清晰；二是业务语义容易建模，不太需要复杂推理；三是价值可量化——客服每天大量重复回答“我的货到哪了”这类问题，Agent 能处理掉 60%，就是实打实的收益。

场景定好了，还要划定边界。建议用下面这张表把需求盘清楚：

这一步不做完，后面都是空中楼阁。

3.2 底座选型：开源模型与框架怎么搭

选底座的时候，需要同时考虑模型框架和 Agent 开发框架。先说模型，现在开源模型已经很强了，DeepSeek、Qwen 这些开源模型在中文业务场景下表现都不错，而且可以本地部署或者走合规的云服务，数据和成本都可控。

Agent 开发框架方面，我自己的经验是：

• 如果团队研发能力强、需要深度定制，选 LangGraph 这类偏底层的编排库，自由度最高。
• 如果团队中业务专家多、开发资源少，可以用 Dify 这类带可视化编排的框架，先把流程跑通。
• 如果业务非常简单，只是问答和简单工具调用，直接用开源的 Harness 项目改也行，但要注意把原项目的业务语义替换掉。

这里给一个粗略的对比表，供大家参考：

我的意见是：不要在框架选择上花太长时间。框架只是骨架，业务语义才是灵魂，选一个团队能快速掌握的开始干，比选一个“完美”的重要一万倍。

3.3 最小可用实现：一个极简 Harness 的代码骨架

为了让大家更直观地理解 Harness，我写一个极简的实现示例。这不是生产级代码，但能说明核心逻辑。假设我们已经有一个订单查询工具：

python复制# harness_demo.py
# 一个极简的 Harness 核心循环：注册工具 -> 模型决策 -> 执行工具 -> 记录审计
import json
from typing import Callable

# 1. 工具注册中心
_TOOLS = {}

def register_tool(name: str, description: str, parameters: dict, func: Callable):
    _TOOLS[name] = {
        "description": description,
        "parameters": parameters,
        "func": func,
    }

# 定义一个业务工具：订单查询
def query_order(order_id: str) -> dict:
    # 实际项目中这里会调用 API，这里简化
    return {"order_id": order_id, "status": "已发货", "eta": "2025-06-01"}

register_tool(
    name="query_order",
    description="根据订单ID查询订单状态和预计到达时间",
    parameters={"order_id": {"type": "string", "description": "订单编号"}},
    func=query_order,
)

# 2. 权限校验（简化示例）
def check_permission(tool_name: str, user_role: str) -> bool:
    # 假设所有已注册工具都可调用，真实环境会按角色和资源做细粒度控制
    return tool_name in _TOOLS and user_role in ("admin", "staff")

# 3. 调用大模型做工具选择的占位函数
def llm_choose_tool(user_request: str, tools_meta: list) -> dict:
    # 真实项目里这里会调用模型接口，并严格指定响应格式
    # 极简示例：默认调用 query_order
    return {"tool": "query_order", "params": {"order_id": "A1001"}}

# 4. 主执行流程
def run(user_request: str, user_role: str):
    audit_log = []
    # 把所有工具的描述发给模型，让模型决策调哪个
    tools_meta = [
        {"name": n, "description": v["description"], "parameters": v["parameters"]}
        for n, v in _TOOLS.items()
    ]
    decision = llm_choose_tool(user_request, tools_meta)

    tool_name = decision["tool"]
    params = decision.get("params", {})

    # 5. 权限校验失败就中止
    if not check_permission(tool_name, user_role):
        return {"error": "permission denied", "audit": audit_log}

    # 6. 执行工具前先记录审计日志
    audit_log.append({"action": "call_tool", "tool": tool_name, "params": params, "user": user_role})

    result = _TOOLS[tool_name]["func"](**params)

    # 7. 记录返回结果
    audit_log.append({"action": "tool_result", "result": result})

    # 8. 格式化最终回答（真实场景再次调用模型）
    return {"answer": f"您的订单当前状态是：{result['status']}，预计到达时间：{result['eta']}", "audit": audit_log}

if __name__ == "__main__":
    resp = run("帮我查一下订单 A1001 到哪了", user_role="staff")
    print(json.dumps(resp, ensure_ascii=False, indent=2))

这段代码把 Harness 最核心的四个逻辑表达清楚了：第一步，把工具集中注册起来，统一管理；第二步，模型只能从注册表里选工具，不能自由发挥；第三步，执行任何工具前都要过权限校验；第四步，所有动作都记录审计日志。

真实项目里，模型不能通过硬编码返回工具，而是要调大模型的接口，同时我会在系统提示词里把工具列表和参数格式写清楚，并强制模型输出固定 JSON 结构，解析失败就重试一次，再失败就转人工。这个“强制结构 + 解析重试 + 兜底人工”的组合拳，能把工具调用的稳定性提升好几个档次。

3.4 业务语义注入与权限控制：从能跑到能用

极简 Harness 跑通之后，真正让它“能用”的关键，是把业务语义注入进去。

最常见的方法是两层：第一层，在系统提示词里写清楚业务背景、术语含义、任务边界；第二层，给每个工具写精细的自然语言描述，让模型知道什么场景该调它、参数怎么填。

举个例子，订单状态不要只写“status”，要写成“订单状态字段，取值范围：pending（待支付）、paid（已支付）、shipped（已发货）、completed（已完成）、cancelled（已取消）”。别小看这几句话，模型对工具的理解能力很大程度取决于工具描述是否具体，字段含义越清楚，幻觉越少。

权限控制也要做成服务化。统一封装一个 permission_service，查询用户角色、资源归属、操作类型三个维度，再决定放不放行。在 Harness 里，每次工具调用都强制走这个服务，不允许任何绕过。另外，敏感字段在返回给模型之前要做脱敏，比如手机号中间四位打码、金额只返回脱敏后的展示值。这两条是合规底线，宁可少一点能力，也不能漏数据。

4. 从 Harness 到业务智能体：四大深化方向

4.1 编排：让 Agent 真正会“走流程”

通用 Agent 是对话式的：你说一句，它回一句。业务智能体是流程式的：一个任务可能需要经过“查询订单 -> 判断交期 -> 检查异常 -> 生成处理方案 -> 人工确认 -> 执行”多个环节，每个环节还有可能分支和循环。

这就是编排引擎要解决的问题。我的做法是把业务流程拆成一个有向图，每个节点是一个原子动作，节点之间用条件边连接。模型负责在节点内部做判断，Harness 负责按流程推动状态流转，而不是全权交给模型自由发挥。

一个典型的订单跟单流程可以长这样：

• 步骤 1：接收用户请求，解析出订单号并要求用户确认
• 步骤 2：调用订单查询工具，获取订单基础状态
• 步骤 3：根据状态分支：如果异常，转人工处理；如果正常，继续查询物流
• 步骤 4：汇总物流信息，生成交付时间线
• 步骤 5：发送给用户，并询问是否需要进一步帮助

把流程显式声明出来，好处是每一步都可控、可回滚、可观测。业务专家看不懂代码，但能看懂这张流程表，他们可以参与优化流程，这是业务智能体能持续演进的根本。

4.2 记忆：会话记忆和业务记忆不能混着来

记忆是 Agent 最常见的翻车点。很多团队把所有历史对话一股脑塞给模型，结果上下文越来越长，模型越来越糊涂，还把 A 客户的信息串到 B 客户那里。

正确的做法是把记忆分成两层。第一层是会话记忆，只保存当前任务的上下文，比如用户刚确认过的订单号；第二层是业务记忆，保存跨会话的长期信息，比如客户偏好、历史处理记录、是否投诉过等。业务记忆建议用结构化的方式存，或者用向量库检索，不能全部堆在 Prompt 里。

还要特别提醒一下记忆的权限隔离。销售人员的 Agent 记忆里存的客户偏好，不能变成其他角色的记忆。业务记忆一定要跟着用户身份走，每个实体（客户、订单、项目）都有一个权限标签，检索时强制过滤。这一点不做好，所谓的智能体迟早变成泄密体。

4.3 安全合规：企业智能体的生命线

说到安全，很多人的第一反应是“防止用户绕过系统”，其实企业 Agent 的安全范围要广得多：

• 提示注入攻击：用户可能通过精心设计的输入，诱导模型执行危险操作，Harness 必须对输入做检测和过滤。
• 工具越权调用：模型在复杂任务里可能“曲线救国”，绕过 A 工具去调 B 工具，权限服务要持续校验，不能只拦第一次。
• 敏感数据泄漏：模型输出时可能复述出训练数据或者上下文里的敏感内容，输出层要做敏感词和内容过滤。
• 审计追踪：每一次决策、每一次调用、每一次异常都要留痕，便于事后追责和优化。

我在实际项目里会把安全规则做成“默认拒绝、显式授权”。所有工具调用，只要没有明确的权限标签，一律拒绝。模型返回的结果，只要包含敏感信息，一律脱敏后再展示。听起来会损失一些“智能感”，但在企业环境里，可靠性永远优先于炫技。

4.4 评估与可观测：没有度量就没有迭代

业务智能体上线不是结束，而是开始。上线后最核心的事就是建评估体系。

第一步是建离线评估集，至少准备几百条真实业务样本，标注好期望回答和关键字段。每次改版，先把这些样本跑一遍，对比正确率、关键字段命中率、幻觉率。第二步是在线可观测，记录每次请求的模型调用成本、响应时间、工具调用成功率、用户反馈等指标。第三步是建立异常告警规则，比如单次工具调用超过三个、连续两次解析失败、敏感内容命中，都要报警。

我见过很多团队上线即解散，原因就是没有建立评估机制，模型一旦变差，所有人都只能靠肉眼去发现问题。事实上，只要评估集建好了，后续模型的升级、Harness 的优化都有了明确的标尺，团队也敢持续动刀。

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

5.1 执行总是中断：terminated due to error 怎么办

很多人在调试 Agent 时会遇到类似的报错，我印象很深的是一条：agent execution terminated due to error.。看到这个不要慌，按我下面的顺序排查：

• 第一步，看日志里的失败节点，是模型调用失败，还是工具调用失败。
• 第二步，检查模型返回有没有被解析成功。经常是模型输出的 JSON 里多了几个空格或者引号不匹配，导致解析崩掉。解决办法是写一个宽容的解析器，或者让模型用结构化输出模式。
• 第三步，检查工具返回的数据是不是过长。某些接口把一个大字段整个返回，直接把上下文撑爆了。解决办法是限制字段数量，截断长文本。
• 第四步，检查是否触发了安全策略，比如权限不足被拒、敏感词拦截导致流程中断。

这一段我吃了很多亏，早期没有把“失败重试+降级转人工”的逻辑做进去，只要工具一报错，整个对话就死掉，用户体验非常差。后来我在 Harness 里专门加了全局兜底：任何环节失败，最多重试两次，再失败就转到人工客服，同时把上下文摘要发给客服。这样 Agent 的可用性一下就上来了。

5.2 模型成本与本地部署：免费模型到底能不能用

经常有人问我有没有可以免费使用的模型。我的答案是：可以免费自部署的开源模型确实存在，但“免费”不代表“零成本”。

DeepSeek、Qwen、Llama 这些开源模型都可以下载到本地服务器上部署，模型权重的获取成本确实很低，但你需要考虑 GPU 算力成本、运维成本、技术团队的人力投入。如果业务量小，用云端 API 按量付费可能更划算；如果数据敏感或者调用量很大，本地部署才会更合适。

另一个容易被忽略的是量化部署。很多企业拿到开源模型就想用全精度跑，结果显存不够。我的经验是先用 4bit 或 8bit 量化跑一个版本，结合 vLLM 推理框架，通常能把同等硬件上的吞吐量提升好几倍，而对最终业务效果的影响往往不明显。先跑起来，再根据评估集决定要不要提精度，这个节奏比较稳妥。

5.3 Harness 和 Agent 不匹配：乱调用与幻觉

业务智能体上线后，常见的问题是“该调的工具不调，不该调的乱调”。这往往不是模型傻，而是 Harness 给模型的约束不够。

我这里有几个调整技巧：

• 把工具描述全部改为“什么场景下用 + 什么时候不用”，比如“查询订单用此工具，查询物流请用另一个工具，不要使用此工具修改订单”。
• 在系统提示词里明确写：“如果用户请求超出你的工具范围，不要编造，直接回复无法处理并转人工。”
• 对模型返回的工具调用结果做校验，如果参数明显不合理，比如缺少必要字段，就直接拦截并让模型重新决策一次。
• 在评估集里专门增加“越权与幻觉场景”，比如“用户要求删除订单”“用户要求查别人的订单”，确保每次改版后这类问题不回归。

说到底，业务智能体不是靠模型自觉，而是靠 Harness 兜底。模型负责灵光，Harness 负责靠谱。

5.4 团队怎么组建：Agent 开发学习路线参考

最后聊一下团队。很多企业卡在“没人会做 Agent”，其实 Agent 开发的门槛没有想象中那么高，但要有一个明确的学习和实践路径。

我的建议是从三条线并行推进。第一条线是“模型与大模型基础”，搞清楚 Prompt 怎么写、模型输出怎么稳定解析、微调和 RAG 的区别；第二条线是“Agent 工程与编排”，学 LangGraph、Dify 这类框架，重点理解工具注册、状态编排、记忆管理；第三条线是“业务建模与评估”，这往往被忽略，但恰恰是最值钱的能力——能把业务流程拆成 Agent 能执行的步骤，能设计评估集，能判断模型输出对不对。

团队配置上，我建议最小编制是“一名熟悉业务的工程师 + 一名业务专家”。工程师负责搭 Harness，业务专家负责梳理流程、整理字段、设计测试用例。两个人紧密配合，跑通第一个场景后，再逐步扩大团队。不要一上来就搞一个十人 AI 组，人多了沟通成本高，反而容易跑偏。

根据我自己的经验，企业自建 Harness 的第一步不是选框架，也不是招大牛，而是先选一个值得做深的业务场景。一个业务场景跑通、沉淀出完整的工具描述、权限规则和评估集之后，第二个、第三个场景就会快很多，因为你的 Harness 已经有了一批可复用的零件。框架随时可以换，模型也随时可能换代，但这些跟着业务一起长出来的 Harness 资产，才是一个企业真正能留住的东西。

如果让我再重来一次，我会把评估集建得更早。哪怕第一版只有几十条样本，也比上线之后靠肉眼发现问题强。记住一点：业务智能体的竞争力，不在于你有多少个 Agent，而在于你对业务的理解，有多少被工程化地沉淀进了你的 Harness 里。