企业官网建设流程全解析

前两篇立了两个观点：Agent 不是 LLM + Tools，而是 LLM 在 Harness 组织下形成的运行形态。也立了一条第一性原理：Harness 存在的唯一理由，就是补齐真实模型和理想模型之间那道缝。

这一篇，我们换一个更直观的比喻。

你招了一个智商 200 的实习生，但他毫无实际工作经验。你让他处理订单，他可能顺手把公司存款捐给慈善机构——动机还挺善良。你问他为什么，他说：“我觉得应该捐。”没有审批，没有记录，只有一脸自信。

你终于明白：这个天才缺的不是脑子，而是一整套工作的边界和规范。

这套规范，就是 Harness。实习生，就是大模型。

真实模型到底缺什么？Harness 到底补什么？答案是六件事：上下文、状态、工具、证据、记忆、策略。

它们不是六个孤立功能，而是同一个原理的六个切面：模型负责推理和判断，Harness 负责让这些判断在真实系统里跑得动、跑得对、跑得住。

1. Context：补的是意图对齐，不是信息堆砌

第一件，缺上下文。

理想模型有无限上下文，永不忘事；真实模型注意力有限，窗口有限，越长越贵，还越长越容易被噪声带偏。

最常见的混淆，是把 Context 当 Prompt。Prompt 关注的是“怎么问”，是一次交互的艺术。但 Agent 要完成的不是一次问答，而是一个跨多步、跨工具、跨状态的任务。每一步，模型都要重新判断“现在该做什么”。它凭什么判断？凭的就是那一刻眼前的 Context。

所以 Prompt 决定怎么问，Context 决定这一步该知道什么、不该被什么干扰。

任务对齐真正需要的，也不是资料，而是意图：目标是什么，背景是什么，边界在哪，什么绝对不能做，怎样算做对，出错的代价多大，什么情况必须停下来找人。

这一整套，我把它叫作 Human Intent。

很多 Agent 后面跑偏、越界、该问人时自作主张，回头追，往往都能追到最初意图没讲清楚。

知道该装什么，还不够。更容易翻车的是：装多少。

直觉是多多益善，这恰恰最贵也最危险。无关内容会变成噪声，模型被十段历史里的一段带偏，去回答一个根本没人问的问题。所以 Context 的目标不是“全”，而是“有用且最小”。它也不应该开局写死，而应该随着任务推进动态组织。

对齐不从模型开始，也不从工具开始，而是从你有没有把意图组织成一份刚好够用的上下文开始。

2. State：补的是运行态，不是让模型自己记进度

第二件，缺状态。

理想模型挂了能自己恢复，所有过程天然连续；真实模型是无状态的，一次调用结束，它并不知道任务真正推进到了哪一步。

Demo 可以一问一答，断了重来；真实任务不行。真实任务是一个过程：现在到第几步，前面做了什么，工具返回了什么，环境变成什么样，哪里失败了，能不能重试，能不能从断点继续。

这些东西不在模型脑子里，必须由 Harness 显式管起来。任务状态、步骤状态、环境状态、工具返回状态，都要有地方存、有办法读、有机制更新。

这和 Memory 不一样。

State 是运行态，回答的是“这个任务现在走到哪了”。Memory 是长期记忆，回答的是“过去沉淀下来的什么经验或知识，此刻可能有用”。

State 丢了，任务就断了。一个长任务跑到第八步崩了，如果没有状态，你只能从第一步再跑，前面七步的成本和副作用全部作废；有了状态，你才能从第八步续上，在失败处重试，把中间产物落盘。

一个没有状态管理的 Agent，看着在干活，其实每一步都在重新开局。它不是能扛住真实任务的执行体，只是一个会动的聊天窗口。

3. Tool：补的是执行治理，不是 Function Calling

第三件，缺对执行的管理。

理想模型工具调用零失误，参数永远正确，也清楚每个动作的业务后果；真实模型会调错工具、传错参数，而且根本不知道某个接口背后会不会产生不可逆的副作用。

Function calling 只解决了一件事：模型能表达“我要调这个工具”。

但从“想调”到“真的执行”，中间还有一长串问题：工具当前是否可用，参数是否合法，前置条件是否满足，返回结果是否可信，失败后能不能重试，会不会重复产生副作用，出了错能不能补偿或回滚。

这些不能交给模型拍脑袋。

关键分工在这里：模型决定“我想做什么”，Harness 判断“这件事怎么被可靠执行、执行完对不对”。

工具要以稳定接口注册和暴露。每次调用要有参数校验、结果校验、失败处理和调用记录。模型的角色是选择和发起，不是无人监管地直接触碰真实系统。

Function calling 是模型的一个能力；工具治理是 Harness 的一层职责。两者不在一个层面上。

4. Trace：补的是证据链，决定 Agent 能不能进生产

第四件，缺证据。

理想模型每一步自动留痕，全程可追溯；真实模型默认什么都不留。你只知道它给了一个结果，不知道它是怎么走到那里的。

一个 Agent 能不能进生产，不只看这次答得好不好，更看出了问题之后能不能复盘。

它用了哪些上下文，为什么调这个工具，工具返回了什么，哪一步被放行，哪一步被拦截，哪一步失败，最后结果怎么来的——这些都要留下来，而且要能按时间顺序回放。

逻辑很直白：没有 Trace 就没有复现，没有复现就没有调试，没有调试就谈不上稳定，谈不上稳定就进不了生产。

企业缺的从来不是能演示的 Agent，而是能上线、能复现、能回放、能验收、出问题能追责的 Agent。

Trace 不是日志洁癖。它是 Agent 工程化的地基，也是 Agent 从“聪明的玩具”变成“系统的一部分”的分水岭。

5. Memory：补的是长期记忆的治理，不是越多越好

第五件，缺记忆。

理想模型有稳定记忆，永不冲突、永不污染；真实模型没有可靠的跨会话记忆，于是大家自然想到 RAG、向量库、长期记忆，然后开始往里灌东西。

但这里有个反直觉的地方：记忆不是越多越好，甚至可能是负资产。

过期的记忆会误导判断，冲突的记忆会让模型无所适从，错误的记忆一旦进去，还会被反复放大。一次错误的“经验”，可能污染之后所有相关任务。

所以 Memory 不是简单的 RAG。检索得到，不等于应该使用。

记忆要治理，就必须有来源、作用域、有效期和写入边界。还要能更新、能废弃、能识别和当前任务的相关性。

尤其是写入这一环，不能交给模型随手决定。模型可以建议“记住这件事”，但不能随手改写自己的脑子。记忆写入必须受控，否则模型会慢慢把自己带进一个越来越偏的世界。

记忆是为了让模型更对齐，不是让它背上越来越重、越来越脏的包袱。

6. Policy：补的是动作边界，决定能不能放行、要不要停下

第六件，也是最容易被忽视的一件，缺策略。

前面五件事解决了该看什么、走到哪、怎么做、留下什么、记住什么。但还有最后一个问题：眼前这个动作，到底能不能发生？

这就是 Policy。

Tool 治理解决的是“动作怎么被可靠执行”，Policy 解决的是“这个动作此刻是否允许发生”。

读一条数据、写一个草稿、修改业务状态、调用外部支付接口，这些动作的风险完全不同。真实系统不能把它们都当成普通的“工具调用”。

Policy 要做的，就是根据任务目标、当前步骤、用户权限、风险等级和历史上下文，对每一次动作做出裁决：低风险动作，放行；高风险动作，要求二次确认；红线动作，直接拦截；需要人拍板的，就停住，等人来点“同意”。

人工介入，正是 Policy 体系里最重要的一种裁决结果。

它不是系统认怂，而是把“人”明确嵌入决策回路，当作最后一道安全开关。什么时候该问人？涉及金额，涉及发布，涉及不可逆操作，涉及敏感数据，模型信心不足，前置证据不充分——这些条件必须提前写进 Policy，而不是事后靠运气。

Policy 让 Agent 敢于在边界内自主，也知道什么时候必须收手。

自主和可控，从来不矛盾。没有 Policy 的 Agent，就像一个没有刹车系统的发动机——能力越强，风险越大。

六件事，其实是一件事

现在，回到开头那个智商 200 但毫无工作经验的实习生。

给他配齐六样东西之后，他不再是那个随时可能捐出公司存款的天才了。他开始先对齐意图再动手，在交接板上记下进度，动用工具前先过检查，每一步自动留痕，记忆只保留有效经验，碰到高风险动作会停下来等你签字。

他依然聪明，也依然可能犯错，但不再失控。

他不是一个完美的神，而是一个被组织进系统边界、能扛住真实任务的执行体。

Context 补的是不知道该关注什么。

State 补的是不记得走到哪。

Tool 补的是动作如何可靠执行。

Trace 补的是不会留下怎么走来的证据。

Memory 补的是没有可靠干净的长期记忆。

Policy 补的是不知道什么时候该做、什么时候该停。

六个缺口，一个原理：这些都是真实模型和理想模型之间的缝，而 Harness 的活儿就是补缝，不是替模型思考。

模型始终是推理、判断、选择的主体；Harness 做的，是把这些判断安放进一个知道该看什么、记得走到哪、管得住怎么做、留得下怎么走、治理得了记什么、也判得清什么时候该收手的系统边界里。

缝补完了。你拥有的不再是一个会调用工具的聊天框，而是一个被组织起来的 Agent。

下一篇，我们就把这六块补丁全部收进 modi-harness，看看一套完整的设计，到底是怎么落成一组可用的原语的。