[I.2] 个人作业:软件案例分析
[I.2] 个人作业:软件案例分析
项目 | 内容 |
---|---|
这个作业属于哪个课程 | 2025年春季软件工程(罗杰、任健) |
这个作业的要求在哪里 | [I.2] 个人作业:软件案例分析 |
我在这个课程的目标是 | 学习软件工程的基础知识,在结对以及团队任务中实践各种开发方法与流程,学会如何与其他开发者更好地合作,和我的组员们一起开发一个让我们值得骄傲的项目 |
这个作业在哪个具体方面帮助我实现目标 | 对市面上的软件进行全面的了解与分析,为之后的软件开发打下基础 |
第一部分 调研与评测
一、选题
我选择“团队项目选题所针对的软件的案例”进行分析。主要分析千帆AppBuilder的工作流Agent,并与文心AgentBuilder等AI原生应用开发平台进行横向对比。
二、软件使用
千帆AppBuilder的工作流Agent通过串联多个智能体,包括了Rag(检索增强生成),结合大模型能力与工具调用,实现复杂任务的自动化执行,帮助用户快速搭建高效、智能的业务流程。
创建新的工作流Agent
添加组件&调整参数

调试
通过API调用Rag
发布
发布后可以通过API&SDK调用发布的应用
三、软件分析
1. 产品基本流程描述
(1)用户根据业务场景设定任务目标,比如自动客服、文档摘要、智能推荐等
(2)通过新建组件或YAML配置添加多个Agent(Rag、数据库)
(3)为每个节点配置使用的大语言模型、提示词、上下文输入来源、工具调用(如搜索、检索、函数执行)
(4)通过平台内置的调试功能查看每一步执行效果,调整提示词和工具参数,优化生成结果。
(5)将工作流部署为API服务,嵌入企业应用或者在千帆平台前端集成为网页应用。
2. 是否满足用户需求?
整体上,千帆AppBuilder 能有效满足企业和开发者在智能自动化、知识问答、文本处理等领域的需求。其模块化、可视化的设计降低了技术门槛,让非技术用户在不了解代码的情况下也能构建复杂的大模型应用。
3. 优缺点分析
优点 | 缺点 | |
---|---|---|
数据量 | 依托百度千帆平台,支持大模型处理大规模文本、知识库、向量检索等,支持PDF、Word等文档上传,自动分块 | 对于极大规模、多文档并发检索的场景,性能仍有待进一步优化 |
界面 | 千帆AppBuilder采用了可视化的拖拽式界面,使得用户不需要编程基础就能够快速构建工作流。 | 对于较大且复杂的工作流,界面的可读性可能会有所下降,尤其是当工作流节点过多时,界面的布局和缩放优化还需进一步加强。 |
功能 | 平台支持多种功能模块,满足任务自动化的需求。它还支持与RAG、大语言模型、API调用等能力的灵活结合,能够有效应对多样化的应用场景。 | 不支持封装,复用性不高,并且企业级协作功能缺失 |
准确度 | 能够准确地找到自己需要的组件 | 结果准确度仍受限于工作流中各个大模型本身推理波动 |
用户体验 | 上手简单,非技术用户也能构建流程 模块拖拽、参数配置门槛低 | 错误提示不明确,调试时如果工作流发生错误不会提示具体是在那个组件中发生的 |
综上所述,千帆AppBuilder在易用性、功能集成度和大模型能力支持方面表现出色,特别适合希望快速构建智能自动化应用的用户。然而,对于更复杂的业务需求,尤其是企业级的协作和精细化控制,可能还需要一些额外的工具或自定义扩展。
四、改进建议
通过软件分析我们发现:千帆AppBuilder在易用性、功能集成度和大模型能力支持方面表现出色,特别适合希望快速构建智能自动化应用的用户。然而,对于更复杂的业务需求,尤其是企业级的协作和精细化控制,可能还需要一些额外的工具或自定义扩展。
-
界面优化
(1)随着工作流复杂度增加,组件的数目和组件之间的流线都会变多,界面的可读性可能受到影响。(2)对于用户已经搭建的应用,如果想想要在其他应用中复用这个已完成的应用则需要在内部重新进行搭建。可复用性和可读性都不高。所以希望千帆AppBuilder能够添加一个已搭建应用的封装功能,提高可读性和可复用性来优化界面。 -
企业级协作功能
千帆AppBuilder在企业级协作和管理方面仍然有提升空间。建议增加团队协作功能,如版本控制、工作流共享、权限管理等,方便多个用户共同开发和维护工作流。此外,可以为大团队提供更细致的操作权限设置,确保不同成员在不同角色下能够有针对性地进行工作流的设计与优化。
五、用户调研
采访对象:软工王德庆老师班sty同学,他从未使用过和工作流有关的应用开发工具。他的需求是找到一个简单易用且高效的工具链,以便于快速学习和开发和AI相关的应用。故他能从初学者的角度提供对千帆AppBuilder的反馈。
Q:你以前使用过类似的通过工作流开发大模型应用的工具链吗?
A:我之前没有使用过类似的工具,但对这样的工具链很感兴趣。
希望能有个简洁的工具,能够让我快速创建一些功能性的原型应用,不想花太多时间在复杂的开发上。
Q:使用完千帆AppBuilder后,你觉得它符合你的要求吗?
A:是的!它的的界面非常简洁,而且操作起来非常直观。我没怎么接触过工作流开发,
虽然一开始面对控制面板有些不知所措,但是摸索一会就能明白它的工作流程了。
Q:那么在使用过程中遇到了什么亮点或是需要改进的地方吗?
A:嗯,除了操作直观之外它的另一大亮点是应用广场提供了很多像是“金牌销售”、“MBTI”的模板。
用户可以通过下载这些模板理清组件的构成和它们之间的运行逻辑。
我作为一个刚入门的新人并没有觉得有什么需要改进的地方,也许在面对比较复杂的应用构建时才会暴露它的问题?
六、评测结论
a) 非常不推荐
b) 不推荐
c) 一般
d) 好,不错
e) 非常推荐
选择d:对于新手来说非常友好,上手极快,但并不适合构建业务比较复杂的企业级应用。
Bug 分析和提交
严重性评级标准
5星级:核心功能严重故障,导致系统崩溃或数据泄漏。
4星级:功能故障严重影响使用流程,用户体验差。
3星级:次要功能问题,影响用户体验但不阻碍主功能。
2星级:轻微问题,对用户影响不大。
1星级:细节问题,不影响整体使用。
Bug 1:
-
测试环境:Windows 11 版本26100.3476操作系统、Microsoft Edge 版本 134.0.3124.66(64位)、Google Chrome 版本 134.0.6998.37(64位)
-
可复现性:每次必现
-
复现步骤:点击个人空间中的应用使自己创建的应用可见,点击编辑按钮后进入应用的操作界面,点击左上角应用头像下方的“AI生成”按钮后头像陷入加载状态但永远无法加载出AI生成的头像。
-
Bug 描述与截图:
Bug现象为点击AI生成头像后头像一直无法加载出来
点击左侧“AI生成”按钮
头像无法一直无法完成加载
-
Bug 分析:
成因推测:
- 接口异常:AI服务接口可能超时或请求失败,导致头像无法生成。
- 前端错误处理不足:未能处理接口失败,导致加载状态一直保持。
- 浏览器兼容问题:可能存在跨域、权限或API兼容性问题,导致功能无法正常执行。
- AI服务繁忙:可能公司的很多服务同时调用某个图像生成AI的API导致AI服务的繁忙,头像无法被正常加载。
严重性分析:
2星级:轻微问题,对用户影响不大。
虽然无法正常用AI会映像用户的体验,但是用户仍可以通过头像上传为自己的应用赋予满意的头像。
- 可能未修复原因:
- 开发人员粗心大意。
- 测试不到位:测试未覆盖特殊浏览器或配置环境,未检测到该问题。
- 开发进度紧张:可能因时间压力未能完善该功能。
- 不影响产品的使用:该功能并不是必须功能,企业可能觉得该功能没什么用。
- 改进建议:
正常行为应该是点击AI生成按钮后应该在30秒内为用户生成一个头像
- 增加错误处理、优化接口稳定性:增加请求超时机制,失败时展示明确错误信息而不是让用户长时间等待,若失败则返回明确的错误状态码。
- 如果无法达到上述要求话直接删除该功能也不是不行。
- Bug反馈:
Bug1
Bug2:
-
测试环境:Windows 11 版本26100.3476操作系统、Microsoft Edge 版本 134.0.3124.66(64位)、Google Chrome 版本 134.0.6998.37(64位)
-
可复现性:每次必现
-
复现步骤:点击调试按钮与自己搭建的AI原生应用进行对话时AI的头像与设置一致,而用户的头像与显示的不一致。这个问题在他人使用我创建的应用时也会发生。
-
Bug 描述与截图:
现象为用户头像显示有误
调试过程中用户头像错误
在他人使用我搭建的应用时用户头像错误(用户并不能匿名使用我搭建的应用,此时用户处于登陆状态)
-
Bug 分析:
成因推测:
- 在调试或公开使用模式下,头像可能使用了静态默认图,而不是动态获取当前用户信息。
- 前端调用头像的路径出现错误,前端头像组件可能错误地调用了默认路径或缓存头像数据。
严重性分析:
1星级:并不是功能性问题,只是显示有问题。并不影响用户使用应用功能。
- 可能未修复原因:
- 开发人员粗心大意
- 测试不到位
- 开发进度紧张
- 改进建议
正常行为应该是同时显示用户头像和应用头像或者同时都不显示
- 最简单的方法就是删除该功能。市面上主流的模型,比如chatGPT在对话过程中并不会显示头像。
- 检查前端头像调用路径并进行修正,在对话中正确显示当前用户真实头像
- Bug反馈
第二部分 分析
一、工作量估算
根据题目要求6人团队配置,开发一个类似千帆AppBuilder工作流的平台大致需要投入3个月时间。平台核心是可视化工作流系统,需支持拖拽节点、参数配置和流程连接,前后端需紧密协作完成。智能体调度、上下文管理、模型调用、工具与API集成、RAG检索等功能也需各模块配合实现,整体逻辑复杂。调试工具、调用链展示、日志系统等是提升用户体验的关键部分。UI界面还需在交互细节、响应布局上打磨,确保低门槛操作体验。
二、软件质量分析
1. 将千帆AppBuilder工作流Agent和文心智能体AgentBuilder相比较
千帆AppBuilder 的工作流 Agent 模式相比文心智能体的 AgentBuilder,具有更强的流程编排能力和更灵活的工具集成。它支持通过拖拽方式构建复杂的多智能体协作流程,节点可以串联多个模型、API 工具、RAG 检索等,适合构建多步骤、异步执行、分工明确的智能流程。这使得 AppBuilder 更适用于需要多个角色协作解决问题的场景。
相比之下,文心智能体 AgentBuilder 更偏向单智能体配置,注重智能体本身的知识、技能、人格设定等,适合构建一个具备个性和长期记忆的“虚拟角色”。它的流程控制能力较弱,虽然有简单的对话逻辑设置,但不具备AppBuilder那样可视化、多分支、多模型联动的能力。因此在复杂流程表达上略显局限。
2. 同类产品排行
- AppBuilder 的优势在于流程灵活、功能集成全面、可视化上手快,适合工程师和产品经理快速搭建复杂智能体工作流。
- 劣势是封装和复用性较差,面对复杂场景时很难让工作流变得有序、清晰。
- 与同类工具如 Langflow、Flowise、ChatDev 等相比,AppBuilder 在中文场景支持、模型集成能力、企业服务对接方面处于较强水平。
综合质量估计在同类工作流智能体平台中可排名前3,尤其在中文环境下具备显著优势。若在灵活性、复用性与模板生态方面进一步提升,有潜力成为国内最领先的智能体工作流平台之一。
3. 具体建议
综合上述分析,千帆AppBuilder的最大问题出现在了控制上。工作流不好控制体现在封装、复用性差;版本不好控制导致协作开发困难、大型企业很少将其视为开发工具。所以建议实现工作流版本控制系统并引入模块化封装机制来增强千帆AppBuilder的控制功能。
第三部分 建议和规划
一.市场现状
1. 市场概况
智能体工作流平台市场正快速扩展,直接用户为企业AI开发者、产品经理等,预计达 10 万级别;潜在用户包括中小企业、非技术人员等,潜在规模超百万,处于成长期。
2. 竞争产品
主要竞争来自:
- Langflow / Flowise:开源强大,适合开发者,但上手难。
- 文心 AgentBuilder:偏单体,缺乏流程控制。
- 通义灵码 AgentFlow:适合编程协同,流程功能较弱。
- Lagent Studio 等新兴平台:功能仍在完善中。
这些产品多聚焦智能体本身,缺乏工作流编排能力。
3. 产品定位与竞争态势
-
Langflow / Flowise
面向技术开发者的开源可视化Agent工作流平台。功能强大、模块灵活、社区活跃、可本地部署。上手门槛高、中文支持差、不适合非技术用户。 -
文心AgentBuilder
聚焦人格化智能体构建的对话型平台。中文能力强、一体式长对话体验好。流程编排弱、灵活性不足、非任务导向。 -
通义灵码AgentFlow
代码生成辅助型Agent协作平台。与IDE融合紧密,适合开发者。可视化编排弱,面向泛业务能力有限。 -
Lagent Studio等新兴平台:
探索阶段,偏技术预览和体验。起步快,接入大模型能力较新。功能不完善,缺少完整流程控制和稳定生态。
由于现在此类基于大模型的应用的需求快速增长,市场正处于百家争鸣期,无明显垄断者。国外产品更强于灵活性和开源生态,国内厂商构建的场景多样、应用性强。不过目前流程型、任务导向平台仍较稀缺,谁能先满足这些需求谁便有可能占领先机。
二.市场与产品生态分析
1. 核心用户群与典型用户画像
千帆 AppBuilder 的核心用户和为AI应用的开发者,包括企业中的开发者和高校中的研究人员。
典型用户具有的特征应该包括:
- 学历:本科及以上,掌握一定的编程技术和AI领域知识储备
- 年龄:25~40岁
- 专业:计算机、人工智能、软件工程等
- 爱好:关注AI工具、自动化、开源平台、生产力工具
- 收入:中等偏上,企业员工或自由开发者为主
- 表面需求:希望快速创建AI工作流程、构建自动化智能体、实现业务提效
- 潜在需求:降低开发门槛、快速验证AI产品原型、个性化定制智能助手,甚至实现低代码开发产品化
2. 用户关系与用户生态
产品用户之间存在协作关系,常见于企业内的产品、开发、运营等角色围绕同一流程共同构建与使用。不同组织的用户也可能共享相似场景,具备流程和模板的复用价值。若平台支持流程共享、模板发布等机制,有望形成以协作与复用为核心的用户生态,促进活跃与增长。
3. 子产品与相关产品的生态关系
千帆AppBuilder工作流依托于百度的很多产品,包括:
- 文心一言:提供模型调用、对话能力
- RAG服务:支持知识问答与企业数据接入
- 知识库工具:支持文档管理、索引生成
- 插件市场 / API集成平台:扩展第三方服务调用能力
这些相关产品之间存在一定的关系,通过 AppBuilder 将它们编排成完整流程,实现了“从模型到场景”的产品生态。如果后续开放更多低门槛插件接入与模板共享机制,则有希望将产品生态更加完善。
三.产品规划
1.新功能设计:
智能体模板市场 + 流程协作机制
功能描述
在现有 AppBuilder 的基础上,引入智能体模板市场与多人协作流程编辑功能,支持开发者封装自己开发好的工作流并发布,用户一键复用他人构建的工作流,同时允许多人共同编辑一个工作流(可设置权限),提升效率与生态活跃度。
为何选这个功能?
- 目前平台模板复用能力弱、用户生态尚未形成。
- 用户希望少从零开始构建流程,更希望基于现成模板快速调整。
- 多人协作是团队真实需求,尤其在企业内部使用中常见。
NABCD 分析:
- N:用户想要快速复用他人经验、多人协同完成复杂流程。
- A:引入模板市场 + 协作编辑机制,支持收藏、评分、复制。
- B:显著降低使用门槛,增强用户粘性,提升生态活跃度。
- C:Flowise等平台无模板共享机制,文心AgentBuilder不支持多人编辑,有差异化优势。
- D:结合百度模型与工作流能力,实现封装复用+协作,有望形成国内领先的智能体协作平台。
2.团队角色配置建议(6人)
项目经理(1人):统筹计划与进度,协调团队沟通。
前端开发(2人):负责界面、流程图交互、协作模块UI实现。
后端开发(2人):负责模板存储逻辑、权限控制、多用户操作同步等。
测试工程师(1人):全流程测试模板发布、协作操作等新功能,确保稳定性。
3.16周项目实施规划
第 1~2 周:需求分析,竞品调研,技术选型,原型初稿
第 3~4 周:前后端架构设计,数据库设计,完成 UI 原型
第 5~6 周:搭建模板市场基础功能(上传/浏览/复制),完成基础协作模块设计
第 7~8 周:模板评分收藏功能上线,协作功能前端交互开发
第 9~10 周:多人协作编辑核心逻辑开发与联调
第 11~12 周:权限系统、模板推荐机制完善
第 13~14 周:全功能联调、Bug 修复、稳定性优化
第 15 周:小范围内测,收集反馈
第 16 周:正式版本上线,撰写文档,启动推广