Agent 工程化物理化体系全景——从概率到确定性的完整工程路径

体系之问：为什么 Agent 会「忘记」查知识库？为什么同一个知识库、同一个模型，不同编排产出天差地别？为什么改一行 prompt 全线翻车？——这些问题的答案，都在「工程化」三个字里。

我做了 52 天的 Agent 工程化实践，踩过大量坑，也沉淀了一套「物理化自动应用体系」。这篇文章是总章——把散落在各篇的碎片串成完整体系，并且每种做法都讲清楚：假设是什么、前提是什么、边界在哪里。

〇、核心思想：确定性优先，概率性被约束

假设

LLM 是概率系统——同样的输入可能产生不同输出，会幻觉、会遗忘、会不遵守指令。

推论

能确定的，就不要让 LLM 决定（用代码/规则/脚本）
必须让 LLM 做的，就用「约束」包住它（注入+验证+免疫）

边界

这套思想的适用前提：任务有「正确标准」（格式、规则、事实可验证）。如果任务是开放创意（写诗、头脑风暴），过度约束反而有害。

一、物理化约束体系（支柱A）

1.1 规则物理化（SOP 注入）

做法：把「必须怎么做」写成规则文件，在每次 LLM 调用前用 hook 物理注入（pre_llm_call）。

假设：LLM 会「忘记」读规则——所以不能靠「记得」，前提：规则文件存在且精简（head -100，毫秒级读取），边界：只适用于硬约束类知识（违反=事故）。参考类知识（客户偏好/历史数据）量大动态，全量注入会爆上下文——该让 LLM 按需检索。

1.2 门禁验证（Post-hook）

做法：产出后用脚本验证（行数/格式/禁词/链接），不通过禁止推送。

假设：验证标准可代码化，前提：脚本真实挂载（pre-commit hook / 发布前强制跑），边界：门禁是「事后惩罚」，保证「不推垃圾」但不保证「一开始就对」——需要和输入约束配合。

1.3 产物溯源标记

做法：产出物带「由流水线产出」的标记，门禁检查标记存在性。

边界：适合「产出物唯一路径」的场景；多入口任务（如邮件系统）不适合单一标记。

二、消除幻觉的工程化（支柱B）

2.1 输入约束（机制链注入）

做法：把关键推理链直接写进 context，不让 LLM 自己检索拼装。

假设：LLM 自己检索不可靠（可能拿不到/拿不全），前提：推理链可由确定性代码生成（从结构化数据推导），边界：适用于「专家一眼看出推理过程」的专业场景；不适用于量大动态的参考知识（该检索）。

2.2 推理约束（SOP + 结构模板）

做法：固定章节结构、禁止「暂无数据」、要求每节有实质内容。

2.3 输出验证（Evals + Golden Dataset + LLM-as-Judge）

做法：

轨迹评估：测过程不测答案（答案全绿过程全错也是错）
Golden Dataset：把过去犯的错固化成回归门禁
LLM-as-Judge：裁判本身要被校准（golden set→一致性→门槛）

2.4 免疫回灌（错误入账→规则物理化）

做法：错误→error-ledger→提取根因→固化规则（技能/脚本/门禁）→再不犯。

边界：这条链路的前提是「错误可归因、规则可形式化」——模糊错误（「回答不够好」）难以物理化。

三、记忆与上下文（支柱C）

3.1 先查索引再喂（RAG 轻量版）

做法：不把知识库全量喂给 LLM——先建索引，查相关片段，只喂相关。

假设：知识库有结构（节点/蒸馏卡），边界：适合中小知识库；库大了该上向量检索。

3.2 上下文管理边界

边界：上下文是稀缺资源——全量注入会爆（实测 Chroma 检索每次拖 3-11s，hook 超时被丢弃）。

四、错误免疫体系（支柱D）

做法：事故→入账→修复→回灌规则（四步闭环）。假设：组织会反复踩同一个坑，除非系统有免疫力。边界：免疫=「改得以后不会坏」；修复=「改回正常」——两者不同，免疫是更高目标。

五、多Agent协作（支柱E）

做法：MCP（工具协议）+ A2A（Agent间协议）+ AG-UI（人机交互层）+ Supervisor（多Agent管理）。

边界：多Agent不是越多越好——复杂度上去才需要；否则单Agent+好上下文更稳定。

六、工程化演进路径（支柱F）

演进阶梯：Prompt → Context → Loop → Graph → 平台。边界：不要跳层——直接上 Graph 而 Context 没做好 = 图里全是「失忆的节点」。

七、可信度验证（支柱G）

做法：Maker/Checker 分离 + 自动化验证（三明治）+ 物理门禁编排。假设：自产自销=自欺欺人——产出者与校验者必须分离。

八、知识注入方法论（支柱H）

核心：给 Agent 的不是知识库，是「用知识的路径」。分流：硬约束→注入；参考→检索；数据→脚本加工。

九、Agent 运维与可靠性（支柱I）

做法：健康检查→自动重启→异常告警→日志轮转（无人值守）；可观测性三件套（门禁/审计/纠正）。

边界：工具隔离与最小权限是安全底线——Agent 行为边界必须锁死。

十、如何落地：给从业者的路径

第一阶段（1周）：把「硬约束」物理化——规则文件+SOP注入+门禁脚本
第二阶段（2周）：建错误免疫——error-ledger+纠正沉淀+回灌
第三阶段（3周）：知识注入——机制链写进context，参考知识按需检索
第四阶段（持续）：演进——从单Agent到多Agent，从Loop到Graph

每阶段前提：先有真实业务场景（不是玩具），先有「正确标准」（可验证），先有错误记录（不是空白）。

十一、边界与局限（体系的前提/假设/代价）

假设	代价	边界
任务有正确标准	过度约束限制创意	开放任务少用规则
规则可形式化	维护成本（写规则/脚本）	模糊错误难物理化
验证可代码化	门禁可能误拦	需人工抽检校准
推理链可生成	需要领域专家提炼	无专家场景难注入
知识有结构	需要建索引/蒸馏	无结构知识难检索

十二、此刻的你

LLM 是概率的，业务需要确定。
Agent 工程化的全部工作，就是在两者之间架桥：
物理化约束（桥墩）、消除幻觉（护栏）、错误免疫（养护）、知识注入（桥面）。

这套体系不是理论——是我 52 天在真实业务里跑通的：
规则注入是代码、门禁是脚本、错误入账是文件、免疫是闭环。
每一步都有物理证据，不依赖任何人的自觉。

如果你的 Agent 还在「凭感觉工作」，是时候给它装上一套物理化体系了。

关于作者无记——AI / Agent / 数智化转型实践者。只写亲手跑通的东西，不聊概念。关注我，一起把认知变现。

魏无记