辅助人完成营销业务
自然语言会话承接查询、理解、解释和人工介入,让用户始终能看见并影响正在推进的业务。
SYSTEM ARCHITECTURE / MARKETING AGENT
以长期 Goal 为生命周期边界,通过用户主导的通用流与 Agent 主导的业务流并行协作,让营销工作既可被辅助完成,也可被持续推进。
自然语言会话承接查询、理解、解释和人工介入,让用户始终能看见并影响正在推进的业务。
Agent 按业务目标主动编排与执行节点,只在需要决策、确认或异常处理时把控制权交还给用户。
营销业务通常持续数周或数月,且同一成员会在多个业务中承担不同角色。系统以 Goal 而非一次性 Session 组织持续上下文、角色目标和多个阶段性任务。
graph TD
Member[营销团队成员] --> Role[业务角色]
Role --> Targets[业务目标 / 季度目标]
Targets --> Goal[Goal\n长期、独立、可分享、可调整]
Goal --> Context[Goal 上下文\n目标、约束、历史状态]
Goal --> TaskA[营销任务 A]
Goal --> TaskB[营销任务 B]
Goal --> TaskN[营销任务 N]
TaskA --> Update[阶段性结果与进度更新]
TaskB --> Update
TaskN --> Update
Update --> Goal
Goal --> Next[后续任务持续加入]
classDef goal fill:#e1f0ed,stroke:#0c6b62,color:#17212b,stroke-width:2px;
classDef task fill:#ffffff,stroke:#9baab2,color:#17212b;
class Goal,Context goal;
class Member,Role,Targets,TaskA,TaskB,TaskN,Update,Next task;
Goal 是长期、独立的业务目标实体;它承载持续状态,而非随着单次对话结束。
目标从人员在具体业务中的角色出发,允许同一成员同时参与多个 Goal。
一个 Goal 可以包含多个营销任务,任务的阶段性结果持续反哺 Goal 状态。
两个流共存在同一个 Goal 生命周期中,互不阻塞。通用流由用户发起;业务流由 Agent 主动推进。两者通过工具和上下文注入实现状态同步与协作。
graph TD
Goal[Goal 生命周期] --> Parallel[通用流与业务流\n并发共存、互不阻塞]
Parallel --> React
Parallel --> GraphExec
User[用户] --> React[通用流:ReAct Agent\n用户发起会话、查询、状态解析]
React --> Snapshot[业务图快照查询 Tool]
React --> Adjust[业务图调整 Tool]
GraphExec[业务流:Graph Execution\nAgent 主动推进、动态节点编排、任务执行]
GraphExec --> Status[业务图状态 / 节点结果 / 任务进度]
GraphExec --> Handoff{需要人工干预\n或确认?}
Handoff -->|是| User
Handoff -->|否| GraphExec
React -. 当前会话上下文注入 .-> GraphExec
Snapshot -. 查询当前图状态 .-> Status
Adjust -. 介入调整业务图 .-> GraphExec
classDef goal fill:#e1f0ed,stroke:#0c6b62,color:#17212b,stroke-width:2px;
classDef react fill:#e2f0f4,stroke:#15708c,color:#17212b;
classDef business fill:#f9e8da,stroke:#b65b22,color:#17212b;
class Goal goal;
class User,React,Snapshot,Adjust react;
class GraphExec,Status,Handoff business;
负责用户可见、可控的自然语言交互,也提供对正在运行的业务图进行查询与调整的入口。
将用户需求映射为动态节点编排,并主动执行营销任务;无需等待通用流完成才继续。
业务流每次加载上下文时都会引入当前通用流会话信息;关键决策再通过 handoff 交回用户。
业务流不是固定工作流。它根据当前营销需求选择、组合和编排已有节点,并将执行结果更新回任务与 Goal,使长期业务可以持续演进。
graph TD
Need[营销需求 / 任务待办] --> Resolve[解析需求与当前任务状态]
Resolve --> Compose[选择并动态编排\n已有业务节点]
Compose --> Build[生成业务图]
Build --> Load[加载执行上下文]
GoalCtx[Goal 上下文] --> Load
ChatCtx[当前通用流会话上下文] --> Load
Load --> Run[执行当前节点]
Run --> State[发布节点状态与产出]
State --> Gate{是否需要\n人工干预或确认?}
Gate -->|需要| Handoff[Hand off 至通用流]
Handoff --> Human[用户确认 / 调整]
Human --> Replan[调整图或恢复执行]
Replan --> Run
Gate -->|不需要| Next{是否还有\n后续节点?}
Next -->|有| Run
Next -->|无| Update[更新任务阶段结果]
Update --> GoalUpdate[更新 Goal 状态与进度]
GoalUpdate --> FollowUp[等待或接收后续营销任务]
classDef source fill:#e1f0ed,stroke:#0c6b62,color:#17212b;
classDef action fill:#f9e8da,stroke:#b65b22,color:#17212b;
classDef handoff fill:#e2f0f4,stroke:#15708c,color:#17212b;
class GoalCtx,ChatCtx source;
class Resolve,Compose,Build,Load,Run,State,Gate,Next,Update,GoalUpdate,FollowUp action;
class Handoff,Human,Replan handoff;
业务图按当前需求构建,复用已有业务节点,而不是预先固化为单一营销流程。
执行时同时读取 Goal 的长期状态和通用流的即时会话内容,避免两种信息孤立。
Agent 默认连续推进;当决策需要人的判断、确认或编辑时,才暂停并 handoff。
一个营销任务图可能包含多个专业环节。当当前节点需要其他角色参与时,系统在协作卡片中指派阶段任务:fork 当前 Goal 与任务状态,携带阶段上下文派发给协作者,并通过飞书完成触达。
graph TD
Current[当前营销任务图] --> Need{当前阶段需要\n其他角色协作?}
Need -->|否| Continue[继续执行当前任务图]
Need -->|是| Card[协作卡片\n选择协作者、任务要求、验收标准]
Card --> Fork[Fork 当前 Goal 与任务状态]
Fork --> Package[携带当前阶段上下文\n目标、任务状态、输入、约束]
Package --> Dispatch[创建协作任务并指派给协作者]
Dispatch --> Feishu[飞书提醒]
Feishu --> Collaborator[协作者接收任务]
Collaborator --> Work[进入系统完成协作任务]
Work --> Return[完成后 handoff 回派发者]
Return --> Accept{派发者验收通过?}
Accept -->|是| Update[更新当前任务阶段状态]
Update --> Continue
Accept -->|否| ReDispatch[补充反馈并二次派发]
ReDispatch --> Dispatch
classDef source fill:#e1f0ed,stroke:#0c6b62,color:#17212b;
classDef action fill:#f9e8da,stroke:#b65b22,color:#17212b;
classDef human fill:#e2f0f4,stroke:#15708c,color:#17212b;
class Current,Need,Continue,Update source;
class Card,Fork,Package,Dispatch,Accept,ReDispatch action;
class Feishu,Collaborator,Work,Return human;
Fork 让协作者获得当前阶段所需的 Goal 与任务快照,同时保留原任务图作为主流程的持续边界。
协作卡片定义任务指派人与协作者、阶段上下文和验收标准;飞书只承担外部提醒与到达入口。
协作者完成任务后 handoff 回派发者验收;不符合要求时携带反馈二次派发,直到阶段状态可更新。
基础能力不直接替代营销业务流,而是为所有 Goal、任务和协作节点提供统一的交互载体、状态呈现、阶段产物管理和知识上下文能力。
graph TD
Runtime[Goal + 双流 Agent + 任务 Graph] --> Foundation[系统基础能力层]
Foundation --> Cards[卡片类型与交互\n展示、操作、确认、指派、验收]
Foundation --> GoalView[Goal 状态显示\n目标进度、健康度、阶段、待办]
Foundation --> GraphView[任务 Graph 进展与状态\n节点状态、依赖、阻塞、执行轨迹]
Foundation --> Artifact[阶段产物展示\n文档、数据、结论、审批结果]
Foundation --> Knowledge[知识库沉淀与检索装载\n沉淀经验、索引检索、上下文注入]
Cards --> UserAction[用户操作 / Agent 触发]
GoalView --> Decision[判断下一步与是否需要介入]
GraphView --> Decision
Artifact --> Knowledge
Knowledge --> Context[装载到通用流、业务流和协作任务上下文]
Context --> Runtime
UserAction --> Runtime
classDef runtime fill:#e1f0ed,stroke:#0c6b62,color:#17212b,stroke-width:2px;
classDef foundation fill:#f9e8da,stroke:#b65b22,color:#17212b,stroke-width:2px;
classDef capability fill:#e2f0f4,stroke:#15708c,color:#17212b;
class Runtime,Context runtime;
class Foundation foundation;
class Cards,GoalView,GraphView,Artifact,Knowledge,UserAction,Decision capability;
提供统一的卡片协议与渲染能力,覆盖信息展示、操作确认、任务指派、协作验收等交互形态,让 Agent 输出可以被执行。
Goal 视图表达长期目标状态;任务 Graph 视图表达节点进展、依赖、阻塞与执行轨迹,两者共同支撑下一步决策。
阶段产物作为任务结果被展示、引用和沉淀;知识库负责索引、检索并将相关内容装载回各类 Agent 上下文。
本图描述系统能力、实体和状态关系,不假设具体模型、存储、编排引擎或业务节点实现。