Linwit-ai-agentic-pt/docs/产品发展.md

我看了你这个用户侧雏形 E:\project_file\ai-agentic-pt，它现在已经不是“展示页”，而是一个很明确的 用户智能体门户：

• 有登录与受保护路由。
• 有广场 Plaza。
• 有智能体推荐、热门、最新、系统智能体。
• 有权限申请 AgentApply。
• 有执行页 AgentExecute，已经接 Dify /v1/info、/v1/parameters、/v1/workflows/run、/v1/chat-messages。
• 有“我的推荐/标记”能力。
• 有历史页、可用智能体页，但这两块目前还是静态雏形。

所以我会把你的整体产品定义成两端：

管理平台：给管理员、运营、架构师、智能体开发者用
用户平台：给普通业务用户、员工、客户、合作方使用智能体

更准确一点：

管理平台 = 智能体控制台 / Agent Control Plane
用户平台 = 智能体工作台 / Agent Workspace

这两个平台不要混在一起。你现在这个方向是对的。

总体定位

我建议你把 Dify 改造后的管理平台定位为：

智能体的创建、发布、治理、调度、监控平台

把 ai-agentic-pt 定位为：

用户发现、申请、使用、订阅、协作智能体的平台

二者关系应该像这样：

管理平台负责生产和治理智能体
用户平台负责消费和使用智能体

也就是：

管理平台：
谁能创建智能体？
智能体如何配置？
有哪些工具和知识？
是否上架？
谁能用？
怎么审批？
怎么监控？
怎么计费？
怎么审计？

用户平台：
我能用哪些智能体？
哪些智能体适合我？
怎么申请权限？
怎么发起任务？
怎么查看结果？
怎么收藏常用智能体？
怎么继续历史会话？
怎么让智能体定期帮我做事？

这个边界非常重要。边界清楚，后面架构就不会打架。

一、用户平台应该怎么做

我建议用户平台不要做成“Dify 应用列表壳子”，而要做成 企业级 AI 工作入口。

用户打开平台时，不应该只看到一堆智能体卡片，而应该感受到：

这里是我使用所有 AI 能力的统一入口。

核心一级菜单建议是：

首页
广场
我的智能体
任务
历史
知识/文件
审批
个人设置

如果你的用户是企业内部员工，推荐结构：

首页
- 推荐给我的智能体
- 最近使用
- 待处理任务
- 我的申请进度
- 常用入口

广场
- 推荐
- 热门
- 最新
- 按部门
- 按场景
- 按行业
- 系统智能体
- 外部智能体

我的智能体
- 已授权
- 我收藏的
- 最近使用
- 即将过期
- 申请中
- 被拒绝

任务
- 我发起的任务
- 定时任务
- 待确认任务
- 执行中
- 失败任务
- 任务结果

历史
- 对话历史
- 工作流执行历史
- 文件生成记录
- 下载记录
- 可复用结果

审批
- 我的申请
- 待我审批，若用户也是主管
- 审批记录

个人设置
- 个人资料
- API Key
- 通知偏好
- 数据授权

你现在已经有：

广场
智能体
可用智能体
历史
申请
执行

我建议下一步把它整理成：

首页 / Dashboard
广场 / Plaza
我的 / My Agents
任务 / Tasks
历史 / History

其中“智能体”侧边栏的二级推荐可以保留，但不要让它承担全部导航职责。

二、用户平台和管理平台怎么打通

最关键的是建立一套明确的发布和消费链路。

我建议定义一条完整生命周期：

管理员创建智能体
-> 配置工具、知识、模型、权限
-> 测试
-> 设置上架信息
-> 设置访问策略
-> 发布到用户平台广场
-> 用户发现
-> 用户申请或直接使用
-> 执行对话/工作流/任务
-> 生成历史与结果
-> 管理端查看运行、质量、成本、反馈
-> 迭代新版本

这条链路里面，两个平台分别负责：

管理平台：
创建、配置、发布、权限、审批、监控、版本、审计

用户平台：
发现、申请、使用、收藏、任务、历史、反馈

中间需要一个业务层，不建议让用户平台直接强依赖 Dify 原始 Console API。

你现在 ai-agentic-pt 已经有 /business/* 接口，这是正确方向。未来建议所有用户平台接口都走业务层：

/business/apps/recommended
/business/apps/hottest
/business/apps/latest
/business/apps/list
/business/apps/:id/basic-info
/business/apps/:id/access-status
/business/apps/:id/access-requests
/business/apps/:id/api-key
/business/agent-marks
/business/agent-pros

继续扩展时也保持这个风格：

/business/me/agents
/business/me/tasks
/business/me/history
/business/me/approvals
/business/me/notifications
/business/apps/:id/reviews
/business/apps/:id/feedback
/business/apps/:id/usage

不要让用户侧关心 Dify 里的 app、workflow、advanced-chat、agent-chat 这些内部实现太多。用户侧应该看到的是：

智能体
任务
结果
权限

而不是：

Dify App
Dify Workflow
Dify API Key
Dify Service API

这些可以在技术层存在，但产品层要隐藏。

三、用户平台最应该补齐的产品闭环

你现在已经有雏形，但还缺几个闭环。

1. 发现闭环

现在广场已经有推荐、热门、最新、系统智能体。下一步应该补：

分类
搜索
标签
适用部门
适用场景
权限状态
是否已收藏
是否可直接使用
是否需要申请

智能体卡片上不要只展示名称和描述，建议展示：

智能体名称
一句话价值
适用场景
权限状态
使用次数/热度
评分或满意度
最近更新
创建方
是否官方

卡片按钮根据状态变化：

公开智能体：立即使用
需申请：申请使用
申请中：查看进度
已授权：打开
已拒绝：重新申请
外部智能体：打开外部服务 / 申请集成权限

你现在已经在做 getAppApiKey 判断，这很好。但产品层最好不要每次点击才判断，可以列表接口直接返回：

{
  "access_status": "available | need_apply | pending | rejected | private",
  "is_marked": true,
  "can_execute": true
}

这样用户不会点击后才突然跳申请页，体验更稳。

2. 权限申请闭环

AgentApply 已经做得有雏形了，有状态、有轮询、有重新申请。下一步建议补：

申请理由模板
申请用途
使用频率
所属项目
数据范围
期望有效期
审批人
审批 SLA
审批记录
被拒原因
重新申请

申请不是单纯“我要用”，而是企业权限治理的一部分。

权限模型建议至少有：

public：公开，登录用户可用
protected：需要申请
department：部门内可用
role_based：指定角色可用
private：不可申请，仅管理员分配
external：外部系统授权

当前你代码里有 public / partial / private，可以先用，但未来建议扩成上面的业务语义。

3. 使用闭环

AgentExecute 现在已经能执行 workflow 和 chat，这是非常关键的主功能。下一步要让它从“技术执行页”变成“用户工作台”。

用户进入一个智能体后，应该看到：

智能体介绍
适合做什么
输入区
参数表单
对话/执行区域
历史结果
常用模板
收藏
反馈
重新运行
导出结果
分享结果
创建定时任务

特别建议在执行页加两个能力：

保存为任务
设为定时任务

比如用户跑了一次“生成周报”，填好了参数。系统应该让用户：

以后每周五 17:00 自动运行这个智能体，并把结果发给我。

这会直接把用户平台和你前面想做的“定时任务模块”连接起来。

4. 历史闭环

你现在 History.jsx 还是静态数据。这个页面很重要，不应该只是“历史记录列表”，而应该成为用户的 AI 工作成果库。

建议历史分成：

对话历史
工作流执行历史
任务结果
生成文件
失败记录
收藏结果

每条历史至少有：

智能体
标题
输入摘要
输出摘要
执行状态
开始时间
耗时
消耗 token / 成本
可查看详情
可继续对话
可重新运行
可导出
可反馈

后台对应需要记录：

conversation_id
workflow_run_id
app_id
user_id
inputs
outputs
status
error
started_at
ended_at
elapsed
metadata

不要只依赖 Dify 原始日志。你需要用户平台自己的业务历史表，用来做用户视角的聚合。

5. 任务闭环

这是我认为你下一步最有战略价值的一块。

用户平台里的“任务”不是管理平台里的“调度配置”。用户视角应该是：

我让哪个智能体帮我做了什么事？
现在做到哪一步？
结果在哪里？
失败了怎么办？
下次什么时候执行？

建议任务模块设计为：

任务列表
- 一次性任务
- 定时任务
- 事件触发任务
- 等待我确认
- 已完成
- 失败

任务详情
- 任务目标
- 绑定智能体
- 输入参数
- 执行计划
- 当前状态
- 执行日志
- 输出结果
- 失败原因
- 重试
- 暂停/恢复

这和管理平台的关系是：

用户平台：用户创建和查看自己的任务
管理平台：管理员治理全局任务、队列、失败、权限、审计

同一个任务系统，不同视角。

四、管理平台应该怎么支撑用户平台

为了让用户平台好用，管理平台不能只做“Dify 原始配置”。它要多出一层“上架运营能力”。

建议在管理端给每个智能体增加这些字段：

上架状态
- 未上架
- 内测
- 已上架
- 下架

展示信息
- 用户侧名称
- 一句话介绍
- 详细介绍
- 图标
- 分类
- 标签
- 适用人群
- 示例问题
- 输入示例
- 输出示例
- 使用说明

权限策略
- 公开
- 申请制
- 部门可见
- 角色可见
- 指定用户
- 私有
- 外部授权

申请策略
- 是否允许申请
- 默认审批人
- 是否自动审批
- 有效期
- 最大调用次数
- 成本额度

运营策略
- 推荐分
- 是否热门
- 是否官方
- 排序权重
- 上架时间
- 最新版本说明

运行策略
- 并发限制
- 调用频率限制
- 超时
- 重试
- 敏感操作确认

质量策略
- 评分
- 反馈
- 成功率
- 平均响应时间
- 最近失败率

这些字段不一定属于 Dify 原始 apps 表。更建议你单独建业务表，比如：

business_agent_listing
business_agent_access_policy
business_agent_access_request
business_agent_mark
business_agent_usage_history
business_agent_task
business_agent_feedback
business_agent_category

不要把用户平台运营字段硬塞进 Dify 核心表。那样未来升级 Dify 会很痛。

五、推荐的整体架构

我建议最终架构是：

用户平台 ai-agentic-pt
        |
        | /business/*
        v
业务 API 层 / Portal API
        |
        | 读写业务表
        v
业务数据库
        |
        | 调用 / 代理
        v
Dify Console / Service API
        |
        v
Dify Runtime / Workflow / Chat

更完整一点：

[用户平台]
- 广场
- 我的智能体
- 执行页
- 申请
- 任务
- 历史
- 反馈

[业务 API 层]
- 认证适配
- 智能体上架
- 权限申请
- API Key 代理
- 任务调度
- 历史聚合
- 用户推荐
- 审批流
- 通知

[Dify 管理平台]
- 创建应用/智能体
- 配置模型
- 配置工具
- 配置知识库
- 配置工作流
- 监控日志

[调度与执行]
- Celery / Scheduler
- Redis Queue
- Dify Service API
- Webhook / 外部系统

[治理]
- RBAC
- 审计
- 成本
- 限流
- 版本
- 评测

重点是：用户平台不要直接变成 Dify 的另一个皮肤，而要有自己的业务 API 和业务数据模型。

六、你现在这个用户平台的具体建议

基于我看到的文件和功能，我建议这样推进。

第一步：先把信息架构收敛

现在路由是：

/plaza
/agents
/history
/available
/agents/execute/:appId
/agents/apply/:appId
/agents/external/:agentProId

建议调整产品概念为：

/plaza                  广场
/my/agents              我的智能体
/my/tasks               我的任务
/my/history             历史记录
/agents/:id             智能体详情
/agents/:id/apply       申请使用
/agents/:id/run         使用智能体
/agents/external/:id    外部智能体

即使代码暂时不改，也建议产品文档和后端接口按这个心智设计。

第二步：把 AvailableAgents 从静态改成真实“我的智能体”

这个页面应该调用：

GET /business/me/agents

返回：

{
  "id": "...",
  "name": "...",
  "description": "...",
  "icon": "...",
  "access_status": "available",
  "expires_at": "...",
  "last_used_at": "...",
  "is_marked": true,
  "usage_count": 12
}

它应该合并：

已授权智能体
收藏智能体
最近使用智能体
申请中智能体

可以用 tabs：

全部
已授权
收藏
申请中
即将过期

第三步：补智能体详情页

现在广场点击后直接去执行或申请。这个路径很高效，但缺少“了解这个智能体”的中间页。

建议新增：

/agents/:id

详情页负责展示：

介绍
示例
权限状态
版本
创建方
使用说明
评价
最近更新
使用按钮/申请按钮

用户从广场点卡片先到详情页。卡片上的主按钮可以直接“使用/申请”，但详情页必须有。

这是平台感的关键，不然广场像一堆快捷方式。

第四步：把执行历史做成真实业务历史

目前 AgentExecute 里执行 Dify SSE，但用户历史页没有接真实数据。建议执行开始和结束时，业务层记录：

POST /business/runs
PATCH /business/runs/:id
GET /business/me/runs
GET /business/runs/:id

如果暂时不好全量代理 Dify SSE，至少在前端执行开始前创建一条业务 run，结束后把摘要、状态、耗时写回业务 API。

长期更建议由后端代理 Dify 执行，这样历史、权限、审计、限流都能集中控制。

第五步：加入任务中心

这是你要做“面向用户智能体应用平台”的杀手锏。

用户不是每次都主动打开平台聊天，很多场景是：

每天给我生成日报
每周总结销售线索
当有新工单时自动分类
当客户发邮件时自动生成回复草稿
每小时巡检系统日志
每月生成经营分析

用户平台应有：

创建任务
选择智能体
填写输入
选择触发方式
选择输出方式
确认权限
查看执行结果

管理平台则有：

任务模板
调度策略
队列监控
失败重试
全局审计

这两个是同一个任务系统的两张脸。

第六步：自然语言入口

用户平台也应该有自然语言入口，但和管理平台不同。

管理平台自然语言入口是：

帮我创建一个智能体
帮我配置权限
帮我发布到销售部门
帮我加一个定时任务模板

用户平台自然语言入口是：

我想做一个销售周报
帮我找能处理合同审核的智能体
以后每天 9 点提醒我看线索
帮我把这份文件交给合适的智能体处理

用户平台的自然语言入口应该像一个 智能体路由器 / AI 助理前台：

用户说需求
-> 系统识别意图
-> 推荐智能体
-> 自动填充参数
-> 发起执行/申请/任务

举例：

我想分析一下这个月销售数据。

系统应该回复：

推荐使用：销售数据分析智能体
需要上传：销售数据表
可选输出：图表报告 / 管理摘要 / Excel 明细
是否现在开始？

而不是让用户自己逛广场找卡片。

七、两个平台之间的对象模型建议

我建议你把“智能体”抽象成业务层统一对象，不要让用户平台直接区分太多 Dify 内部类型。

Agent
- id
- source_type: dify_app | agent_pro | external | composite
- source_id
- name
- description
- icon
- category
- tags
- owner
- status
- visibility
- access_policy
- listing_info
- runtime_config

用户侧看到的是 Agent。

管理侧可以看到更细：

Dify App
Workflow
Chat App
External Agent
Agent Pro
Composite Agent

权限对象：

AgentAccess
- user_id
- agent_id
- status
- granted_by
- granted_at
- expires_at
- quota
- scope

申请对象：

AgentAccessRequest
- user_id
- agent_id
- reason
- status
- approver_id
- rejected_reason
- created_at
- updated_at

运行对象：

AgentRun
- id
- user_id
- agent_id
- task_id
- mode
- inputs
- outputs
- status
- error
- started_at
- ended_at
- cost
- trace_id

任务对象：

AgentTask
- id
- user_id
- agent_id
- title
- trigger_type
- schedule
- inputs
- output_target
- status
- next_run_at
- last_run_at

反馈对象：

AgentFeedback
- run_id
- user_id
- agent_id
- rating
- comment
- issue_type

这些对象是用户平台和管理平台共同的“语言”。

八、产品策略建议

我建议你不要一上来做“万能超级智能体平台”。先做一个很清楚的闭环：

管理员发布智能体
用户发现智能体
用户申请权限
用户使用智能体
用户查看历史
用户收藏智能体
用户创建定时任务
管理员看使用数据和反馈
管理员迭代智能体

这条闭环跑通以后，再做自然语言创建和多智能体协作。

推荐 MVP 优先级：

P0
- 广场真实列表
- 智能体详情
- 权限申请
- 执行页稳定
- 我的智能体
- 真实历史记录

P1
- 收藏/推荐
- 分类/搜索/标签
- 使用反馈
- 管理端上架配置
- 管理端审批
- 用户侧任务中心

P2
- 定时任务
- 通知
- 审批流
- 成本/额度
- 自然语言找智能体
- 自然语言创建任务

P3
- 自然语言创建智能体
- 多智能体团队
- 任务模板市场
- 行业方案
- 自动评测和优化建议

九、我最建议你现在做的架构决策

第一，保留两个平台，不要合并。
管理平台复杂、面向专业角色；用户平台轻、面向业务用户。合并会让普通用户看到太多配置，也会让管理端被用户体验约束。

第二，抽出业务 API 层。
用户平台所有东西走 /business/*，不要直接调用 Dify Console API。Dify Service API 的执行可以短期前端直连，但长期最好后端代理。

第三，智能体上架信息独立建模。
不要把广场、推荐、权限、申请、热度、评分这些都塞进 Dify 原生 app。你要做的是“Dify 之上的智能体运营层”。

第四，任务中心从一开始按平台级能力设计。
不要只做“cron 页面”。用户侧叫“任务”，管理侧叫“调度/任务治理”，底层同一套任务模型。

第五，自然语言入口分两类。
管理平台的自然语言是“创建和管理智能体”；用户平台的自然语言是“找到、使用、委托智能体”。

第六，历史和审计要自己掌握。
这是平台价值沉淀的地方。只靠 Dify 内部日志，用户侧体验和管理侧治理都会受限。

十、推荐你形成的最终产品形态

我会把最终形态想成这样：

用户打开 AI agentic 平台
-> 首页看到推荐智能体、最近任务、待处理事项
-> 可以在广场找智能体
-> 可以用自然语言描述需求，让平台推荐智能体
-> 可以申请权限
-> 可以直接使用智能体
-> 可以把一次执行保存为定时任务
-> 可以在历史里查看所有 AI 工作成果
-> 可以给结果反馈

管理员打开管理平台：

创建智能体
-> 绑定知识、工具、模型
-> 设置用户侧展示信息
-> 设置权限和审批
-> 发布到广场
-> 查看申请和使用数据
-> 查看失败、成本、质量
-> 调整版本
-> 下架或灰度发布

这就是一个完整的“双平台智能体系统”：

管理平台负责供给
用户平台负责消费
业务 API 负责连接
任务系统负责持续执行
治理系统负责安全可控

我的结论很明确：你现在的 ai-agentic-pt 应该继续做，而且应该把它从“智能体广场雏形”升级成“用户 AI 工作台”。管理平台不要承担用户使用体验，管理平台只负责创建、发布、治理和监控。两端通过统一的业务智能体模型、权限模型、任务模型、历史模型打通。

如果下一步只选一个最重要的方向，我建议先做：

智能体详情 + 我的智能体 + 真实历史 + 任务中心雏形

这四个补齐之后，用户平台就从“能点开智能体”变成“真的能日常工作”。