写在前面

Hi。好久不见，距离上次写文又过去了半年啦。这半年又有一些实践和想法，想整理一下和大家交流～

上一篇还是去年底写的。那时候关于智能化相关的实践更多在「探索可使用阶段」。把多智能体、知识库、上下文工程这些能力搭起来让业务流程跑通。能出结果，

这半年做的事情是“爬楼梯”式的探索常用方法。不再是「让它能跑」，而是想尝试着回答一个很实际的问题：一套依赖大模型的程序。怎么才能让业务团队敢放心用？

上半年做了哪些事呢？落地了一些或许对于目前我遇到的业务场景可能是常用方法的技术方法：DAG 编排引擎、Harness、ReAct、协调者—多智能体、令牌桶限流、两级产出校验、统一事件流协议…，。

这篇文章，主要想聊一聊上半年做的这些能力项：用了什么技术、为什么这么设计、踩过什么坑、最终怎么解的。

价值大概汇总成三点：

• 让 AI 真正懂业务——、知识工程、记忆管理、规划能力，把业务领域知识、任务意图、历史上下文精准喂到模型面前；
• 让 AI 真正会干活——编排骨架、智能体循环、ReAct、思维链、DAG、多智能体、技能抽象、协议接入、函数调用、工具使用，把一个复杂任务从头做到尾；
• 让 AI 真正靠得住——事件流协议、防护自省、安全护栏。可观测性，评估程序，让每一步说得清，拦得住。

OK。那接下来就开始正文了～

目前做的网站一直是for业务同学的，就是研发和测试。整体产品主要是：把业务同学「理解需求 → 测试分析 → 编写用例 → 自动化执行 → 集成发版」这条又累又重复链路交给 AI 来完成。

使用者痛点一： 业务团队常抱怨手工测试耗时长且易出错。希望能把重复性工作交给机器，却担心AI生成的不确定性会导致更大的风险。我们的目标就是解决这一痛点。说起来，

This entire system rests on a dual‑engine architecture: one side is a deterministic orchestration engine。responsible for “按步骤把活干完”;不过，or is an exploratory reasoning engine。responsible for “搞清楚使用者到底想干嘛，动态决定接下来”。In short: deterministic tasks go through DAG orchestration;exploratory tasks use ReAct reasoning;y complement each or.

The real challenge is that large models are inherently probabilistic generators – y can time out,hit rate limits。return empty responses,hallucinate or claim success without actually persisting files. 使用者痛点二： 这种不确定性直接影响生产可用性与成本控制，需要一种稳健可靠的方法来建立生产程序。不过，

让 AI 真正「懂业务」

：Prompt / Spec 双文件 + 渐进式上下文注入

• .prompt.md 和 .spec.md 分离： 每个功能拆成两份文件。prompt 关注推理逻辑与角色设定；spec 管理输出格式与结构约束。这样可以让产品同学专注输出格式而不必涉足推理细节，也方便后续校验复用 spec 文件。
• 渐进式上下文注入： 将所有材料分层注入。层本轮必需输入，第四层共享上下文补充。 避免一次性塞满 context 而稀释关键信息，并降低 token 消耗。
• 使用者痛点三："提示词被硬编码在代码里"导致难以维护与迭代，尤其当业务需求变更频繁时会出现大量 diff 与 review 的负担。我们通过将提示词外置为文件解决此问题。
• 常用方法提醒："提示词禁止内联进代码"。因为散落字符串无法 diff 或 review，一旦改漏就会产生不可追溯的问题。

知识建模 → 注入 → 验证闭环。多维向量融合检索

• 关键区别：KJ ≠ RAG — RAG 只是检索片段并注入 Prompt，而完整闭环包括“知识建模 → 知识注入 → 知识验证”。
• BGE 向量语义检索替代关键词检索："下单流程" 可以召回 "购物车结算" 等同义表达，提高召回率并降低误匹配概率。
• 多维向量融合："Word2Vec 抓词级精确匹配"、“Sentence-BERT 抓句级语义相似”还有“Doc2Vec 抓文档级主题”，根据场景选取或综合打分来获取最合适的信息片段。其实，
• Few-shot 样例质量很关键："如果示例包含错误或格式不对。它们会被 LLM 学习并复制出来。" 所以一定要使用真实可执行且无瑕疵的数据样本进行训练与验证。

记忆管理这方面，工作记忆 / 共享黑板 / 会话状态隔离

• 工作记忆:  在单次推理循环期间维护短时状态。如 user_query/analysis_results/loop_history/remaining_tasks 等，以便 ReAct 循环中的思考–行动–观察能够连贯传递信息。
• 共享黑板:  节点间通过零拷贝共享数据。每个节点执行完后自动 merge 到共享上下文，后续节点可以直接读取，不需要序列化/反序列化开销。
• 会话隔离:  不同使用者或任务使用独立 session 并按 token 预算裁剪最近历史。上下文压缩采用 Compact 处理，以保证关键指令始终占据窗口优先位置并避免跨任务污染。

再看规划能力，粗规划 + 细执行分层。意图驱动 Pipeline 选择

• DAG 层负责确定整体流程顺序；ReAct 循环负责动态决策。当收到模糊指令时“UnderstandingEngine” 利用思维链推理判断最可能对应 Pipeline，并抽取参数。随后 ReAct 在每轮中持续评估当前状态并决定接下来行动，这样就能实现动态方法切换而不是一次性制定全局计划。

让 AI 真正「会干活」

编排骨架这方面，Harness 与 DAG 的协作模式

• DAG 用于定义节点依赖关系与拓扑排序；Harness 则横向管理重试限流等通用功能，并为每个节点提供统一日志与状态记录。这样模型只需关注“想”，骨架负责“组织”。这一分离提高了复用率，也降低了模型内部堆积的信息量。使得每个子任务保持轻量级且易调试。

再看智能体循环，ReAct + 双层循环 + CoT 推理展开

• Aggressive Think 阶段先完成一次完整思考链；老实说，随后通过简短思考复用已有记忆。大幅节省 token 并加速响应时间。（)
* **安全护栏**：输出结构化 JSON {action。params,reasoning} 且 action 必须来自白名单，否则由安全模块强制纠正。* **双层循环**：外部 Harness 调度循环 & 内部 ReAct 推理循环。各自计数 & 上限，从而防止无限循环。* **CoT** 本质就是 Think 阶段中展开思维链。可实时观察 AI 的分析方法，使其透明可视。--- --- --- --- --- --- --- --- --- --- ### 有向无环图编排