Business Agent 被定义为能规划多步、改组织状态、并在关键点升级人类的系统——区别于仅生成文本的 chatbot/copilot/RAG；可靠落地依赖六项架构属性而非更长 prompt。
Claim
Business Agent 被定义为能规划多步、改组织状态、并在关键点升级人类的系统——区别于仅生成文本的 chatbot/copilot/RAG；可靠落地依赖六项架构属性而非更长 prompt。
Why it matters
团队常把「会调工具的聊天机器人」误标为 agent，导致无持久记忆、无写权限门禁、无触发器时在 demo 好看、生产崩盘。用可检查的架构清单（记忆/规划/人在回路/集成/角色/触发）可指导 harness 与评测设计。
Summary
Jitera 文提出 Business Agent 六属性：跨会话记忆、规划与失败恢复、恰当时机的人审、读写 SoR （含 MCP）、角色特化、自主触发。缺任一属性会退化成个人提效工具而非组织能力。
Actions
- (none)
Evidence
- (none)
Caveats
- (none)
Research queries
- (none)
Body
什么是 Business Agent（工程清单视角）
背景
「Agent」被滥用于：单轮聊天、带检索的助理、会调一两个 API 的 demo。对企业而言，真正改变结果的是 会改系统状态的多步自治：关工单、发消息、改 CRM、合并 PR。这类系统错误会跨系统传播，因此需要与「个人提效插件」不同的架构。
机制（六属性）
- 跨会话持久记忆：按 agent 的知识图/Context，会话结束不归零；角色知识隔离防污染。
- 规划与失败恢复：计划与执行分离；逐步状态；失败后改编剩余计划；Skills 打包指令+工具。
- 恰当时机的人在回路：不是每步打断，而是在「不可逆/对外」边界升级；确认结果回写记忆。
- 深系统集成：经 MCP 等读写 SoR；读可宽、写需批；风险注解驱动策略。
- 角色特化：Code / Project / Ops 等分 agent，避免单池注意力竞争；支持多人多 agent 同线程。
- 自主触发：cron 与 webhook 拉起（PR 合并、站会摘要），而非永远等人 @。
取舍
- 相对 copilot：牺牲「随时陪聊」的简单性，换组织级闭环与可审计写路径。
- 相对 RPA：用 LLM 规划换柔性，但引入幻觉与权限面，必须门禁与记忆治理。
- 产品文偏差：六属性有助于评审，但落地细节（记忆抽取质量、技能市场）因平台而异。
动作
- 给每个生产 agent 打六属性红绿灯；红灯项进架构债。
- 写操作统一经审批或二次确认策略；评测集加入「越权写」用例。
- 记忆分角色命名空间；定期审计错误实体，防毒化知识图。
- 触发器与权限绑定：webhook 身份校验 + 最小工具集。