一、我们想解决的不只是“读邮件”校园工作里最麻烦的邮件往往并不是最长的那封。比如一次奖学金材料收集可能同时包含正文里的截止日期PDF 里的材料要求后续回复里的补充说明多名学生重复或缺失的附件尚未提交材料的名单最后还需要形成 Excel 台账、情况说明和催办邮件。如果只是让大模型回答“这封邮件讲了什么”其实只完成了最简单的一步。真正耗时的是后面的工作邮件 ↓ 知道发生了什么 ↓ 确认依据在哪里 ↓ 判断下一步做什么 ↓ 找到谁需要跟进 ↓ 生成真正的工作成果因此我们最终把 Postbird 的目标重新定义为把校园邮箱中的信息和证据转化为可追溯的行动与真实可交付成果。对应到系统里就是四个关键词Action · Evidence · Delivery · Human Review二、十日谈9 月 20 日—9 月 29 日这次十日谈我们选择尽可能按照真实开发记录来写。其中部分日期没有独立 Git commit。与其为了满足“十天”形式把每一天包装成一次功能发布我们更愿意保留这些真实空白并说明项目是在什么时候发生关键转折的。Day 19 月 20 日先决定“不从零造一个比赛 Demo”比赛进入作品开发阶段后我们首先面对的是方向问题。当时手上已经有一些 AI Agent、工业智能体、生成式 AI 和本地模型相关工作。如果单纯为了比赛完全可以重新做一个看起来更“炫”的项目。但最后我们逐渐形成一个原则优先选择已经有真实工程基础、能够继续向完整 Agent 演进的项目。Postbird 的优势在于它已经拥有完整的邮件和 Office 操作底座。也就是说我们不需要花主要时间造轮子可以把精力放在 Agent Skills、评测、安全边界和平台适配这些真正决定 Agent 质量的问题上。Day 29 月 21 日让 Demo 开始承担“解释系统”的责任9 月 21 日Postbird 仓库产生了一次可核验的 Demo 相关提交0875907b这一阶段关注的重点已经不仅是“功能能不能点”而是用户第一次看到 Postbird 时能不能快速理解它为什么这样设计我们开始把 Demo 和设计护栏放到一起。例如为什么邮箱读取默认只读为什么没有直接删除邮件的 Tool为什么发送邮件前必须 Preview为什么 Agent 的结论最好能找到原始依据。后来回头看这一步实际上为比赛版的 Human-in-the-loop 和 Evidence-linked 设计埋下了伏笔。Day 39 月 22 日没有新的公开提交开始反思“工具多不等于 Agent 强”这一天公开仓库没有形成独立代码提交。但回看当时的项目状态一个问题越来越明显Postbird 已经有很多工具可是22 个 Tool 并不会自动变成一个优秀的 Agent。如果把所有能力都平铺给模型模型仍然需要自己解决应该先调用哪个工具哪些信息必须查证什么情况下应该停止继续执行什么操作需要人工确认最终输出应该是什么形式。这让我们开始重新思考Agent Skills 的价值也许并不是“再增加一个工具”而是把专业工作流和调用边界固化下来。Day 49 月 23 日把“答案正确”进一步拆成“证据是否可靠”通用大模型很容易生成一段听起来合理的答案。但在真实办公场景里一个更重要的问题是你为什么得出这个结论例如系统判断“某位同学还缺少成绩单。”真正有用的系统应该进一步回答原通知里哪里要求了成绩单哪封邮件是他的最新提交附件里到底有没有这份材料这个判断是确定的还是需要人工复核于是我们把Evidence从一个附属能力提升成独立的一层。后来的比赛版中这一层最终成为postbird-evidence SkillDay 59 月 24 日确认“继续堆功能”的边际收益已经很低到这个阶段Postbird 已经覆盖了邮件生命周期中的大量能力。继续增加第 23、第 24 个 Tool当然还能让功能列表更长。但对一个 Agent 系统来说更重要的问题已经变成这些能力能不能稳定组合起来因此我们开始把整个工作链压缩成三个职责Action判断什么需要处理谁需要跟进截止时间是什么哪些材料缺失。Evidence核查原邮件邮件线程PDFWordPowerPointExcel。Delivery真正形成邮件回复提醒草稿Excel 台账Word 情况说明PPT 汇报材料。这三个词后来成为比赛版 Agent Skills 架构的主体。Day 69 月 25 日确定一个原则——比赛 Demo 只讲一件完整的事Agent 产品很容易陷入一种展示误区功能越多就越想全部展示。Postbird 目前可以覆盖本科生、研究生、辅导员、行政老师、教学老师、教授和学生组织等多种校园角色。但如果在几分钟的视频里依次演示十几个功能最终评委可能一个也记不住。因此我们最终收敛出一个旗舰场景辅导员奖学金材料收集。完整任务是读取相关邮件 ↓ 识别通知要求 ↓ 检查提交状态 ↓ 找到缺件与未交人员 ↓ 回到原邮件/附件核查 ↓ 生成个性化提醒 ↓ 输出 Excel / Word 等成果 ↓ 人工确认后再允许外发这一个场景已经能够同时体现Agent 编排EvidenceOffice 交付安全边界Human-in-the-loop。Day 79 月 26 日从“Demo 能跑”转向“结果能不能被评测”Agent Skills 写得很漂亮并不能证明 Agent 真会使用它。因此我们给三个 Skill 增加了独立评测思路。最终比赛版建立了18 条 eval cases覆盖三类问题Trigger什么任务应该进入这个 SkillBehavior进入 Skill 后应该采取什么行为Boundary什么情况下不应该继续执行比如“附件里报名截止时间是多少”合理路径应该进入 Evidence Skill读取附件并返回依据。它不应该因为看到“报名”两个字就直接进入邮件发送流程。最终仓库提供npm run skill:benchmark当前确定性路由基线为18 / 18这里我们特意没有写“模型准确率 100%”。因为这两件事完全不是一个概念。18/18 表示仓库定义的 deterministic routing conformance 全部通过只是一个可复现的路由基线。Day 89 月 27 日明确安全边界——Agent 可以做事但不能越权我们越来越确定真正能进入办公场景的 Agent 必须知道什么时候停止。Postbird 最终保留了几条很明确的边界。邮箱默认只读读取邮件时尽量避免改变邮件状态。本地优先索引、附件和生成文件优先留在本地环境。Evidence-linked重要结论尽可能能够回到邮件或附件来源。Preview → Confirm → Send涉及真实发送时生成草稿 ↓ Preview ↓ 用户确认 ↓ SendAgent 不能跳过人工确认。我们希望做到的并不是“让 Agent 自动做所有事情”而是让它自动完成可以安全自动化的部分并在应该交还控制权的时候停下来。Day 99 月 28 日重新对照评分标准比赛方案发生真正的收敛9 月 28 日是整个比赛准备过程中非常关键的一天。这一天我们重新从评分标准出发检查项目而不是继续从已有代码出发问“还能再加什么”评分标准真正强调的是Agent Skills智能体和模型深度DGX SparkNVIDIA 技术栈StepFun项目完整性可复现演示。这让我们的目标发生了明显变化。Postbird 不应该被包装成“一个功能很多的校园邮箱助手。”更准确的定位应该是一个通过 Agent Skills 把邮件证据转化为行动和真实办公交付物的 Local-first Campus Office Agent。同时确定比赛运行架构Postbird Agent Skills ↓ Action / Evidence / Delivery ↓ 22 office_* tools ↓ Candidate Result ↓ DGX Spark 本地 Runtime ↓ NVIDIA Nemotron ↓ StepFun Reviewer ↓ Human Review其中DGX Spark 承担本地运行环境Nemotron 作为本地主 Agent / reasoning modelStepFun 承担独立 Reviewer最后的高风险动作仍由人确认。Day 109 月 29 日把“项目”整理成真正可提交、可评测、可复现的作品最后一天的工作量最大。公开仓库当天形成了参赛整理提交c5122ac同时我们围绕比赛版本进一步完成了系统性重构。1. 从单一 Skill 拆成 1 3 Skill System现在结构变成Root Orchestrator ↓ ┌─────┼──────────┐ ↓ ↓ ↓ Action Evidence Delivery Skill Skill Skill三个 Skill 各自包含触发条件推荐工具顺序输出约束失败分支人工复核边界eval cases。2. 建立 18 条 Skill Evaluation Cases不再只描述“这个 Skill 应该很好用。”而是提供可以直接运行的评测入口npm run skill:benchmark确定性路由基线18 / 183. 增加 DGX Spark / Nemotron / StepFun 平台验证链比赛版新增 OpenAI-compatible model runtime并将平台验证独立出来。真实环境下可以执行npm run platform:verify npm run platform:demo我们专门增加了一条规则只有真实运行产生的 evidence 文件中overall_ok: true才能在 README、视频或文章中写“已验证”。这样可以避免把“代码支持”和“真实跑通”混成一件事。4. 把 StepFun 从“API 接入”变成 Reviewer我们并不希望为了平台适配机械地多接一个模型。因此给 StepFun 一个明确角色独立 Reviewer流程变成Nemotron 规划 / 推理 ↓ Candidate Result ↓ StepFun Reviewer ↓ 检查 Evidence 检查遗漏 检查发送风险 ↓ Human Review这个结构比“两个模型都负责回答用户问题”更清晰。5. 做一个完全离线的一键 Demo为了避免比赛视频受到网络API Key邮箱授权本地模型加载临时服务异常影响我们又单独制作了一个 deterministic offline demo。最终 Demo 被打包成一个自包含的index.html双击即可运行。不需要NodenpmPython邮箱API KeyDGX Spark网络连接。CSS、JavaScript、Logo 和 XLSX / DOCX / PPTX 示例全部内嵌。但这里同样保留一个边界离线 Demo 只用于稳定展示产品工作流不冒充真实模型运行。真实平台验证由另一条 evidence chain 完成。三、最终的 Postbird 长什么样我们最终把 Postbird 总结成下面这条链Campus Request ↓ Root Orchestrator ↓ ┌────────────┬─────────────┬─────────────┐ │ Action │ Evidence │ Delivery │ │ Skill │ Skill │ Skill │ └────────────┴─────────────┴─────────────┘ ↓ 22 Office Tools ↓ Verified Deliverables ↓ Human Review它的终点不再是一段聊天回答。而可能是真正的Excel 材料台账Word 情况说明PowerPoint 汇报文件邮件提醒草稿可追溯的邮件与附件证据。四、这十天最大的收获Agent 的难点不是“能不能调用 Tool”做完这一轮之后我们对 Agent 有一个更明确的判断。一个 Tool 很容易写。几十个 Tool 也可以继续堆。真正困难的是模型什么时候应该调用它调用前要检查什么调用后怎么验证什么时候必须停下来交给人所以这次比赛给 Postbird 带来的最大变化并不是工具数量增加了多少。而是从“有很多工具。”走到了“有一套能够组织工具、约束工具、评测工具使用方式的 Agent Skills 系统。”这也是为什么我们最终把系统拆成 Action、Evidence 和 Delivery。五、我们刻意没有写进文章的“漂亮数字”做比赛很容易出现一种诱惑“效率提高 80%。”“准确率达到 95%。”但如果没有严格对照实验这些数字没有意义。所以目前 Postbird 公开展示的指标只保留能够复现的部分。例如22 个office_*tools3 个 focused Agent Skills1 个 Root Orchestrator18 条 Skill eval cases18/18 deterministic routing conformance可真实生成 XLSX / DOCX / PPTX 等 Office 文件下一阶段如果继续做用户实验我们更希望真正测量人工操作步骤数完成任务所需时间漏项数量人工复核次数unsafe-send rate。而不是先写一个看起来漂亮的比例。六、为什么最终仍然保留 Human-in-the-loop我们并不认为办公 Agent 越自动越好。尤其是给学生发邮件批量催办对外通知涉及重要材料判断这些动作一旦错误成本并不低。因此 Postbird 选择的是Agent 负责准备人负责最终决策。它可以帮你查整核写生成文件准备发送。但真正的 Send仍然需要明确确认。我们认为这是从 Demo 走向真实工作流必须保留的一层边界。七、最后我们真正想做的不是一个“更聪明的邮箱”Postbird 的名字是“信鸽”。我们喜欢这个名字是因为信鸽最重要的事情并不是“知道所有事情”而是把正确的信息可靠地送到应该到达的地方。对 Agent 来说也是一样。模型能力当然重要但真正决定一个 Agent 能否进入真实工作的还包括专业流程工具边界EvidenceEvaluationHuman Review可复现工程。所以如果要用一句话总结这次十日谈我们没有在十天里重新做一个 Postbird而是重新理解了 Postbird 应该怎样成为一个 Agent。从校园邮箱开始从一封通知开始最终走到Evidence → Action → Delivery → Review。这可能也是我们在这次 NVIDIA DGX Spark 黑客松里最大的收获。项目信息项目名称Postbird 信鸽项目定位Agent Skills Campus Office Agent核心架构Agent Skills × DGX Spark × NVIDIA Nemotron × StepFun Reviewer × Human-in-the-loop应用场景校园邮件、材料收集、任务跟进与 Office 工作流开源协议MIT项目代码、离线 Demo、Skill 定义、评测脚本以及平台验证方法均随参赛仓库公开。关键词NVIDIA DGX SparkAgent SkillsAI AgentNemotronStepFun智能体校园办公邮件 AgentLocal-firstHuman-in-the-loop
十日谈｜从 22 个工具到可评测的 Agent Skills：Postbird 的 DGX Spark 黑客松实践
一、我们想解决的不只是“读邮件”校园工作里最麻烦的邮件往往并不是最长的那封。比如一次奖学金材料收集可能同时包含正文里的截止日期PDF 里的材料要求后续回复里的补充说明多名学生重复或缺失的附件尚未提交材料的名单最后还需要形成 Excel 台账、情况说明和催办邮件。如果只是让大模型回答“这封邮件讲了什么”其实只完成了最简单的一步。真正耗时的是后面的工作邮件 ↓ 知道发生了什么 ↓ 确认依据在哪里 ↓ 判断下一步做什么 ↓ 找到谁需要跟进 ↓ 生成真正的工作成果因此我们最终把 Postbird 的目标重新定义为把校园邮箱中的信息和证据转化为可追溯的行动与真实可交付成果。对应到系统里就是四个关键词Action · Evidence · Delivery · Human Review二、十日谈9 月 20 日—9 月 29 日这次十日谈我们选择尽可能按照真实开发记录来写。其中部分日期没有独立 Git commit。与其为了满足“十天”形式把每一天包装成一次功能发布我们更愿意保留这些真实空白并说明项目是在什么时候发生关键转折的。Day 19 月 20 日先决定“不从零造一个比赛 Demo”比赛进入作品开发阶段后我们首先面对的是方向问题。当时手上已经有一些 AI Agent、工业智能体、生成式 AI 和本地模型相关工作。如果单纯为了比赛完全可以重新做一个看起来更“炫”的项目。但最后我们逐渐形成一个原则优先选择已经有真实工程基础、能够继续向完整 Agent 演进的项目。Postbird 的优势在于它已经拥有完整的邮件和 Office 操作底座。也就是说我们不需要花主要时间造轮子可以把精力放在 Agent Skills、评测、安全边界和平台适配这些真正决定 Agent 质量的问题上。Day 29 月 21 日让 Demo 开始承担“解释系统”的责任9 月 21 日Postbird 仓库产生了一次可核验的 Demo 相关提交0875907b这一阶段关注的重点已经不仅是“功能能不能点”而是用户第一次看到 Postbird 时能不能快速理解它为什么这样设计我们开始把 Demo 和设计护栏放到一起。例如为什么邮箱读取默认只读为什么没有直接删除邮件的 Tool为什么发送邮件前必须 Preview为什么 Agent 的结论最好能找到原始依据。后来回头看这一步实际上为比赛版的 Human-in-the-loop 和 Evidence-linked 设计埋下了伏笔。Day 39 月 22 日没有新的公开提交开始反思“工具多不等于 Agent 强”这一天公开仓库没有形成独立代码提交。但回看当时的项目状态一个问题越来越明显Postbird 已经有很多工具可是22 个 Tool 并不会自动变成一个优秀的 Agent。如果把所有能力都平铺给模型模型仍然需要自己解决应该先调用哪个工具哪些信息必须查证什么情况下应该停止继续执行什么操作需要人工确认最终输出应该是什么形式。这让我们开始重新思考Agent Skills 的价值也许并不是“再增加一个工具”而是把专业工作流和调用边界固化下来。Day 49 月 23 日把“答案正确”进一步拆成“证据是否可靠”通用大模型很容易生成一段听起来合理的答案。但在真实办公场景里一个更重要的问题是你为什么得出这个结论例如系统判断“某位同学还缺少成绩单。”真正有用的系统应该进一步回答原通知里哪里要求了成绩单哪封邮件是他的最新提交附件里到底有没有这份材料这个判断是确定的还是需要人工复核于是我们把Evidence从一个附属能力提升成独立的一层。后来的比赛版中这一层最终成为postbird-evidence SkillDay 59 月 24 日确认“继续堆功能”的边际收益已经很低到这个阶段Postbird 已经覆盖了邮件生命周期中的大量能力。继续增加第 23、第 24 个 Tool当然还能让功能列表更长。但对一个 Agent 系统来说更重要的问题已经变成这些能力能不能稳定组合起来因此我们开始把整个工作链压缩成三个职责Action判断什么需要处理谁需要跟进截止时间是什么哪些材料缺失。Evidence核查原邮件邮件线程PDFWordPowerPointExcel。Delivery真正形成邮件回复提醒草稿Excel 台账Word 情况说明PPT 汇报材料。这三个词后来成为比赛版 Agent Skills 架构的主体。Day 69 月 25 日确定一个原则——比赛 Demo 只讲一件完整的事Agent 产品很容易陷入一种展示误区功能越多就越想全部展示。Postbird 目前可以覆盖本科生、研究生、辅导员、行政老师、教学老师、教授和学生组织等多种校园角色。但如果在几分钟的视频里依次演示十几个功能最终评委可能一个也记不住。因此我们最终收敛出一个旗舰场景辅导员奖学金材料收集。完整任务是读取相关邮件 ↓ 识别通知要求 ↓ 检查提交状态 ↓ 找到缺件与未交人员 ↓ 回到原邮件/附件核查 ↓ 生成个性化提醒 ↓ 输出 Excel / Word 等成果 ↓ 人工确认后再允许外发这一个场景已经能够同时体现Agent 编排EvidenceOffice 交付安全边界Human-in-the-loop。Day 79 月 26 日从“Demo 能跑”转向“结果能不能被评测”Agent Skills 写得很漂亮并不能证明 Agent 真会使用它。因此我们给三个 Skill 增加了独立评测思路。最终比赛版建立了18 条 eval cases覆盖三类问题Trigger什么任务应该进入这个 SkillBehavior进入 Skill 后应该采取什么行为Boundary什么情况下不应该继续执行比如“附件里报名截止时间是多少”合理路径应该进入 Evidence Skill读取附件并返回依据。它不应该因为看到“报名”两个字就直接进入邮件发送流程。最终仓库提供npm run skill:benchmark当前确定性路由基线为18 / 18这里我们特意没有写“模型准确率 100%”。因为这两件事完全不是一个概念。18/18 表示仓库定义的 deterministic routing conformance 全部通过只是一个可复现的路由基线。Day 89 月 27 日明确安全边界——Agent 可以做事但不能越权我们越来越确定真正能进入办公场景的 Agent 必须知道什么时候停止。Postbird 最终保留了几条很明确的边界。邮箱默认只读读取邮件时尽量避免改变邮件状态。本地优先索引、附件和生成文件优先留在本地环境。Evidence-linked重要结论尽可能能够回到邮件或附件来源。Preview → Confirm → Send涉及真实发送时生成草稿 ↓ Preview ↓ 用户确认 ↓ SendAgent 不能跳过人工确认。我们希望做到的并不是“让 Agent 自动做所有事情”而是让它自动完成可以安全自动化的部分并在应该交还控制权的时候停下来。Day 99 月 28 日重新对照评分标准比赛方案发生真正的收敛9 月 28 日是整个比赛准备过程中非常关键的一天。这一天我们重新从评分标准出发检查项目而不是继续从已有代码出发问“还能再加什么”评分标准真正强调的是Agent Skills智能体和模型深度DGX SparkNVIDIA 技术栈StepFun项目完整性可复现演示。这让我们的目标发生了明显变化。Postbird 不应该被包装成“一个功能很多的校园邮箱助手。”更准确的定位应该是一个通过 Agent Skills 把邮件证据转化为行动和真实办公交付物的 Local-first Campus Office Agent。同时确定比赛运行架构Postbird Agent Skills ↓ Action / Evidence / Delivery ↓ 22 office_* tools ↓ Candidate Result ↓ DGX Spark 本地 Runtime ↓ NVIDIA Nemotron ↓ StepFun Reviewer ↓ Human Review其中DGX Spark 承担本地运行环境Nemotron 作为本地主 Agent / reasoning modelStepFun 承担独立 Reviewer最后的高风险动作仍由人确认。Day 109 月 29 日把“项目”整理成真正可提交、可评测、可复现的作品最后一天的工作量最大。公开仓库当天形成了参赛整理提交c5122ac同时我们围绕比赛版本进一步完成了系统性重构。1. 从单一 Skill 拆成 1 3 Skill System现在结构变成Root Orchestrator ↓ ┌─────┼──────────┐ ↓ ↓ ↓ Action Evidence Delivery Skill Skill Skill三个 Skill 各自包含触发条件推荐工具顺序输出约束失败分支人工复核边界eval cases。2. 建立 18 条 Skill Evaluation Cases不再只描述“这个 Skill 应该很好用。”而是提供可以直接运行的评测入口npm run skill:benchmark确定性路由基线18 / 183. 增加 DGX Spark / Nemotron / StepFun 平台验证链比赛版新增 OpenAI-compatible model runtime并将平台验证独立出来。真实环境下可以执行npm run platform:verify npm run platform:demo我们专门增加了一条规则只有真实运行产生的 evidence 文件中overall_ok: true才能在 README、视频或文章中写“已验证”。这样可以避免把“代码支持”和“真实跑通”混成一件事。4. 把 StepFun 从“API 接入”变成 Reviewer我们并不希望为了平台适配机械地多接一个模型。因此给 StepFun 一个明确角色独立 Reviewer流程变成Nemotron 规划 / 推理 ↓ Candidate Result ↓ StepFun Reviewer ↓ 检查 Evidence 检查遗漏 检查发送风险 ↓ Human Review这个结构比“两个模型都负责回答用户问题”更清晰。5. 做一个完全离线的一键 Demo为了避免比赛视频受到网络API Key邮箱授权本地模型加载临时服务异常影响我们又单独制作了一个 deterministic offline demo。最终 Demo 被打包成一个自包含的index.html双击即可运行。不需要NodenpmPython邮箱API KeyDGX Spark网络连接。CSS、JavaScript、Logo 和 XLSX / DOCX / PPTX 示例全部内嵌。但这里同样保留一个边界离线 Demo 只用于稳定展示产品工作流不冒充真实模型运行。真实平台验证由另一条 evidence chain 完成。三、最终的 Postbird 长什么样我们最终把 Postbird 总结成下面这条链Campus Request ↓ Root Orchestrator ↓ ┌────────────┬─────────────┬─────────────┐ │ Action │ Evidence │ Delivery │ │ Skill │ Skill │ Skill │ └────────────┴─────────────┴─────────────┘ ↓ 22 Office Tools ↓ Verified Deliverables ↓ Human Review它的终点不再是一段聊天回答。而可能是真正的Excel 材料台账Word 情况说明PowerPoint 汇报文件邮件提醒草稿可追溯的邮件与附件证据。四、这十天最大的收获Agent 的难点不是“能不能调用 Tool”做完这一轮之后我们对 Agent 有一个更明确的判断。一个 Tool 很容易写。几十个 Tool 也可以继续堆。真正困难的是模型什么时候应该调用它调用前要检查什么调用后怎么验证什么时候必须停下来交给人所以这次比赛给 Postbird 带来的最大变化并不是工具数量增加了多少。而是从“有很多工具。”走到了“有一套能够组织工具、约束工具、评测工具使用方式的 Agent Skills 系统。”这也是为什么我们最终把系统拆成 Action、Evidence 和 Delivery。五、我们刻意没有写进文章的“漂亮数字”做比赛很容易出现一种诱惑“效率提高 80%。”“准确率达到 95%。”但如果没有严格对照实验这些数字没有意义。所以目前 Postbird 公开展示的指标只保留能够复现的部分。例如22 个office_*tools3 个 focused Agent Skills1 个 Root Orchestrator18 条 Skill eval cases18/18 deterministic routing conformance可真实生成 XLSX / DOCX / PPTX 等 Office 文件下一阶段如果继续做用户实验我们更希望真正测量人工操作步骤数完成任务所需时间漏项数量人工复核次数unsafe-send rate。而不是先写一个看起来漂亮的比例。六、为什么最终仍然保留 Human-in-the-loop我们并不认为办公 Agent 越自动越好。尤其是给学生发邮件批量催办对外通知涉及重要材料判断这些动作一旦错误成本并不低。因此 Postbird 选择的是Agent 负责准备人负责最终决策。它可以帮你查整核写生成文件准备发送。但真正的 Send仍然需要明确确认。我们认为这是从 Demo 走向真实工作流必须保留的一层边界。七、最后我们真正想做的不是一个“更聪明的邮箱”Postbird 的名字是“信鸽”。我们喜欢这个名字是因为信鸽最重要的事情并不是“知道所有事情”而是把正确的信息可靠地送到应该到达的地方。对 Agent 来说也是一样。模型能力当然重要但真正决定一个 Agent 能否进入真实工作的还包括专业流程工具边界EvidenceEvaluationHuman Review可复现工程。所以如果要用一句话总结这次十日谈我们没有在十天里重新做一个 Postbird而是重新理解了 Postbird 应该怎样成为一个 Agent。从校园邮箱开始从一封通知开始最终走到Evidence → Action → Delivery → Review。这可能也是我们在这次 NVIDIA DGX Spark 黑客松里最大的收获。项目信息项目名称Postbird 信鸽项目定位Agent Skills Campus Office Agent核心架构Agent Skills × DGX Spark × NVIDIA Nemotron × StepFun Reviewer × Human-in-the-loop应用场景校园邮件、材料收集、任务跟进与 Office 工作流开源协议MIT项目代码、离线 Demo、Skill 定义、评测脚本以及平台验证方法均随参赛仓库公开。关键词NVIDIA DGX SparkAgent SkillsAI AgentNemotronStepFun智能体校园办公邮件 AgentLocal-firstHuman-in-the-loop