软件架构师罗小东，多年架构和平台产品设计经验，目前在 Agent 场景落地结合中。

这个只是设计的初稿，还在学习和补充，计划三个月左右讨论与补充，年底产出一稿。除了业务层以外的，还有底层的，AgentBench 测评、Trace 可视化、还有 Harness 自己升级自己等很多内容。

概述

你会不会发现一个问题：几乎主流 AI 操作都集中在一个 chatbot 入口，需要你主动去找它，还必须先了解它有哪些能力。换个思路，既然一切都已经 AI 化，为什么不能反过来，让 AI 来找你呢？从“被动聊天机器人”到“主动决策伙伴”。

业务 Decision-Loop 是在原 AIPHarness 引擎基础上，进一步结合业务场景与决策流程优化升级后的产物。它在保留原有引擎核心能力的同时，针对业务需求强化了决策闭环、流程协同与执行反馈能力，使系统能够更稳定、更贴合业务地支持复杂决策场景。

原来的 Harness 设计，面向业务执行，提供了一个业务 + Agent 协同的引擎，让流程编排、任务触发和能力调用能够统一承载；而大模型的应用体现，目前主要就是 Agent，也就是以 Agent 为落地载体，让模型能力参与到具体业务环节。

业务形成闭环，是 Harness 能力上升级的目标之一，也就是目前遇到的 Decision-Loop 循环工程，只是针对于业务场景来说的一个闭环，而人要做的是提供 AI 业务范式，还有确认环节。

什么叫业务形成闭环，比如场景：

• • 商品少了，AI 会自动找你，然后你确认补货，AI 自动处理并告诉你结果；
• • 本周工作计划，明天要做【登录】部分，AI 自动提醒你，你确认方案，AI 自动执行编码；
• • 最新的热点出来了，AI 会告诉你并提供最新的内容方案，你确认方案，AI 自动执行；
• • ……

下面是一个结构较简单、仅用于演示基本功能或思路的基础原型：

以前，你需要主动打开 AI 窗口，输入问题，等待回复；现在，AI 会根据你的上下文、目标和当前场景，主动找到你，提前给出提醒、建议、总结或答案，让交互从“你去问 AI”变成“AI 来找你”。

场景沉淀

定义 Agent 业务目标，自动业务巡检检查 → 输出结构化业务决策结果 → 用户确认 / 修改 / 忽略反馈 → 反馈回流，形成完整 OODA 业务决策闭环（就是文档的 “让系统先开口” Action Hub 范式），将整个过程，把人的操作结果（采纳 / 修改 / 拒绝 / 执行失败）回流，影响下一轮的观测、提醒、方案生成，然后形成业务规范沉淀。

这里规划三个沉淀：

• • 普通记忆[已实现]：短期记忆、长期记忆、项目记忆。
• • 画像[已实现]：用户画像、AI 画像、业务画像。
• • 业务规则[重点]：补货规则、毛利计算规则等。

团队比较执着于走通业务闭环，也就是不满足于单点工具或局部优化，而是希望从场景切入、流程衔接、结果验证到商业落地，形成一个能够持续运转的完整链路。

目前，AI在编程、影视、设计等领域都带来了较大冲击，不仅显著提升了生产效率，也改变了创作方式、协作模式和工作流的组织逻辑。这种变化并不会停留在少数技术敏感型行业，向各行业持续渗透只是时间问题。

这里每个架构师设计不一，我有我思。

业务Loop流程

这里目前初步设计的闭环流程设计，目前不管是 Harness 还有技术应该都是成熟的，在做过的 AI 项目（一个 Agent + 电商闭环流利，已经跑了 2-3 个月）也做了一段时间的验证。

一个持续迭代的闭环运行机制，循环每一轮的输出，会被上一轮的执行结果、人类反馈所改变，不是固定硬编码流程，支持人机介入，这里列了一个大致的流程：

1. 1. 有循环调度：支持定时触发 / 业务事件触发，周期性启动一轮循环；
2. 2. Observe 观测层：持续采集业务现实状态；
3. 3. Orient 推理层：调用 Agent 内核（AIPHarness），支持 dryRun 只出方案不碰数据；
4. 4. Decide 人机决策层：不是自动执行，把决策权交给人，提供多种处理选择；
5. 5. Act 执行层：人工执行 / 用户显式授权后 Agent 执行；风险规则拦截高危动作；
6. 6. Learn 反馈层：把人的操作作为反馈记忆，输入下一轮循环，改变下一轮的产出；
7. 7. 完整可观测：循环每一步都留执行轨迹日志。

针对于业务导向的 Decision-Loop 设计，主要是为了先切入具体业务场景，围绕真实决策流程中的输入、判断、执行、反馈和结果沉淀进行建模，在逐步落地和优化过程中积累可复用的状态流转、策略编排、异常处理与数据记录机制，出一版本通用业务 Decision-Loop Runtime，用于支撑不同业务场景下的快速接入、统一决策闭环运行和持续迭代演进。

这两年大模型的演化大概过程是这样的：

目前在 AIPHarness 上已经完成的沉淀和验证，大致持续了半年左右，其中于今年 3 月份完成了初版架构搭建；随后我们又结合已经沉淀并丢出去的内容做了一轮验证，主要是看这些沉淀能否在实际使用中被继续验证、反馈和复用。

抽取出来的 AIPHarness 层——在业务系统集成过程中，我们对智能体所需的基础能力做了统一的抽象和封装。通用能力包括：

用户画像、上下文、执行沙箱、文件系统、权限系统、MCP/SKILL 工具、消息与事件、计划模式、连接器、专家套件、读写工具、故障恢复、安全规则等。

在通用能力之上，针对业务系统深度集成的场景，又扩展了这些能力：界面交互、积分体系、交互模式、工具分层、SKILL 分层、认证系统等。

在业务层面，已有 2 个场景完成了端到端验证，流程可正常跑通并具备初步可复用价值；另外还有 2 个场景目前仍处于集成验证阶段，正在推进系统间联调和业务闭环校验，待验证稳定后再进入下一步。

结语

这个过程其实可优化的点是非常多的，而且 AIPHarness 层同样需要 Loop 层的设计，先走业务层可以直接看到结果，在过程中再进一步补充底层的设计。

底层的设计会更加复杂，未来计划是 2027 年左右的主攻目标与方向。这也是目前在规划和准备进一步落地的部分，目的是形成智能体的业务场景和解决方案闭环。一些 Loop Engine 建设的经验分享，欢迎有兴趣的朋友讨论。