项目线 B 浏览器 / 办公自动化 Agent

这条项目线适合把“工具调用、工作流编排、人工确认、权限控制、Agent UI”串成一个完整案例。相比企业知识库问答 Agent，它更强调“执行动作”而不是“回答问题”，因此非常适合展示你在 Agent 工程里的流程设计和产品交互能力。

1. 项目定位

1.1 项目目标

做一个能帮助用户完成浏览器或办公场景任务的自动化 Agent，例如：

• 读取网页内容并整理摘要。
• 按步骤填写表单并生成草稿。
• 从文档中提取待办并同步到任务系统。
• 整理会议纪要并生成邮件或周报草稿。

项目目标不是单纯“能自动点按钮”，而是做一个：

• 有明确执行计划。
• 关键动作可确认。
• 执行过程可见。
• 失败后可恢复。
• 可用于作品集展示的任务型 Agent。

1.2 为什么它适合前端工程师

前端工程师天然熟悉：

• 浏览器环境与 DOM。
• 用户交互与表单流程。
• 异步状态与任务反馈。
• 高风险操作的提示与确认。

这些能力非常适合迁移到自动化 Agent 场景里。 与纯问答项目相比，这条项目线更能体现你对“系统执行过程”和“人机协作界面”的理解。

2. 推荐场景选择

建议从低风险、可复现的办公场景切入，不要一开始就做强副作用的自动化。 比较适合作为第一版的场景有：

• 从网页抓取活动信息并整理成结构化摘要。
• 读取会议纪要并生成待办列表。
• 将用户提供的素材整理成邮件草稿或周报草稿。
• 协助填写内部低风险表单，但提交前必须人工确认。

不建议第一版就做：

• 自动付款。
• 自动删除记录。
• 自动发送正式通知。
• 跨多个高权限系统执行不可逆动作。

3. 系统能力地图

这条项目线重点覆盖以下能力：

• Tool Calling：让 Agent 能调用浏览器、文档、搜索和表单类工具。
• Workflow：把复杂任务拆成明确步骤。
• Human-in-the-Loop：让关键节点等待用户确认。
• Observability：记录每一步的执行状态和失败原因。
• Security：控制权限边界和副作用风险。
• UI / UX：把任务过程、执行计划和失败恢复展示给用户。

4. 一套推荐的最小架构

可以按以下层次设计：

• 前端控制台：输入任务、展示计划、展示步骤、确认关键动作。
• Agent 服务层：理解任务、规划步骤、选择工具、汇总结果。
• 工具层：浏览器工具、文档读取工具、表单工具、任务系统写入工具。
• 状态层：任务状态、步骤状态、确认状态、失败原因。
• 日志与观测层：trace、执行轨迹、用户操作记录、失败分类。

可以把主链路理解为：

1. 用户输入任务目标。
2. Agent 先生成执行计划。
3. 用户确认计划或修改约束。
4. Agent 分步骤执行工具操作。
5. 前端展示每一步状态。
6. 高风险动作需要用户确认。
7. 最终生成结果、草稿或可执行下一步。

5. 推荐的第一版 MVP

第一版不要追求“全自动”，而要追求“半自动但可信”。 建议 MVP 具备以下能力：

• 用户输入一个明确任务。
• Agent 输出步骤计划。
• 系统执行只读或低风险步骤。
• 涉及写入或提交时先请求确认。
• 执行结果以结构化形式展示。
• 如果失败，能保留进度并提示下一步动作。

一个很合适的 MVP 示例

“读取一份会议纪要文档，抽取决策项和待办项，生成待办清单草稿，并在用户确认后导出为任务列表。”

这个场景同时具备：

• 文档读取。
• 信息抽取。
• 步骤计划。
• 人工确认。
• 结构化输出。
• UI 展示价值。

6. 实施步骤

第一步：定义任务边界

先写清楚：

• 自动化目标是什么。
• 哪些步骤可以自动执行。
• 哪些步骤必须人工确认。
• 哪些失败必须立即中止。

这一步很重要，因为自动化 Agent 的最大风险往往是边界不清。

第二步：拆任务为节点

建议把任务拆成 4 到 6 个可观测节点，例如：

• 读取输入材料。
• 识别关键内容。
• 生成执行计划。
• 生成草稿结果。
• 等待用户确认。
• 执行导出或写入动作。

拆得太粗会难调试，拆得太细会增加系统复杂度。

第三步：定义工具契约

每个工具至少写清楚：

• 作用是什么。
• 输入参数有哪些。
• 返回什么结构。
• 会不会产生副作用。
• 失败后怎么回退。

例如“导出待办列表”这个工具，至少要说明：

• 是否真正写入任务系统。
• 是否支持 dry-run。
• 失败时是否可重试。

第四步：设计确认机制

浏览器 / 办公自动化场景里，确认机制非常关键。 建议至少有以下一种：

• 执行计划确认。
• 高风险步骤确认。
• 最终结果审核后提交。

大多数情况下，第二和第三种需要同时存在。

第五步：设计前端任务面板

不要只做聊天流。 建议至少展示：

• 当前任务。
• 当前步骤。
• 已完成步骤。
• 等待确认项。
• 失败原因。
• 可执行操作：继续、取消、重试、转人工。

第六步：加执行日志与 trace

这一类项目出了问题时，用户通常会问：

• “你做到哪一步了？”
• “刚才到底提交了吗？”
• “为什么停在这里？”

没有执行轨迹，体验会非常差。

第七步：逐步扩大自动化范围

第一版确认稳定后，再考虑：

• 引入更多工具。
• 支持更复杂的计划。
• 支持多系统协作。
• 支持更高阶的任务恢复。

7. 前端最应该做好的 5 件事

7.1 先展示计划，再执行

用户对执行型 Agent 最关心的是“你准备做什么”。 计划可见会显著提升信任。

7.2 把步骤状态做清楚

不要只显示“执行中”。 至少要区分：

• 计划生成中。
• 步骤执行中。
• 等待确认。
• 部分成功。
• 已取消。
• 执行失败。

7.3 为关键节点提供确认和取消

用户应该始终保有控制权。

7.4 为失败场景提供恢复路径

例如：

• 只重试失败步骤。
• 保留已生成草稿。
• 允许切换为人工处理。

7.5 为结果提供结构化展示

例如：

• 待办列表。
• 草稿邮件。
• 抽取的字段。
• 计划执行日志。

这会比一段自然语言结果更易校验和复用。

8. 推荐指标

第一版项目可以优先关注：

• 计划执行成功率。
• 关键步骤确认率。
• 可恢复失败比例。
• 平均完成时长。
• 用户取消率。
• 用户主观满意度。

如果场景涉及文档抽取，还可以补：

• 信息抽取准确率。
• 结构化结果可用率。

9. 常见坑

9.1 一开始追求全自动

这往往会导致系统风险极高，而且很难建立用户信任。

9.2 没有计划展示

用户不知道系统准备做什么，出现偏差时也无法及时纠正。

9.3 工具失败后从头重来

这样会严重破坏体验。 很多场景应该支持部分恢复。

9.4 确认机制过重或过轻

过重会让用户觉得比手工还麻烦；过轻则会放大风险。

9.5 只做技术链路，不做界面反馈

技术上执行成功，不代表产品体验是成功的。

10. 建议的阶段性交付物

阶段 1：任务型 MVP

交付物：

• 一个任务输入页。
• 一个步骤计划展示页。
• 一个低风险自动化 Demo。

阶段 2：可协作版本

交付物：

• 人工确认节点。
• 任务面板。
• 可取消和重试机制。

阶段 3：可观测版本

交付物：

• 执行轨迹。
• 失败分类。
• 关键步骤耗时统计。

阶段 4：可投递版本

交付物：

• 项目卡片。
• 交互截图或录屏。
• 任务链路图。
• 面试讲述稿。

11. 作品集怎么讲

建议突出以下几个点：

• 你不是做了一个会聊天的机器人，而是做了一个能执行任务的 Agent。
• 你如何拆解任务步骤并控制副作用风险。
• 你如何设计确认机制和失败恢复。
• 你如何把前端交互和执行轨迹做成可信界面。
• 你如何处理工具调用、状态同步和用户反馈闭环。

12. 面试表达

你可以这样讲：

“这个项目的重点不是让 Agent 自动点网页，而是让它在执行多步骤任务时保持可见、可控、可恢复。我先让系统生成计划，再通过工具调用执行低风险步骤，对写入或提交类动作增加确认节点，前端则用任务面板展示执行轨迹和失败原因。这样项目既体现了 Tool Calling 和 Workflow 能力，也体现了我作为前端工程师在人机协作界面上的优势。”

---

13. 自托管部署变体

🏠 零 API 依赖版本

浏览器自动化 Agent 同样可以使用本地模型驱动，适合内网环境和成本敏感场景。

技术栈替换对照

组件	云端版	自托管版
规划模型	GPT-4o	Ollama + Qwen3-8B
执行模型	GPT-4o-mini	Ollama + Qwen3-4B
浏览器控制	Playwright（不变）	Playwright（不变）

自托管改造要点

1. 双模型策略：规划用 8B 模型保证质量，执行用 4B 模型降低延迟
2. 注意事项：浏览器自动化对模型指令遵循能力要求高，推荐 Qwen3 或 Mistral
3. 适用场景：企业内网桌面自动化、CI/CD 集成测试

详细本地模型选型参考 专题 11：自托管 AI Agent 全栈指南