实战指南：如何用 100 行代码构建一个自动预订会议的 AI Agent Harness Engineering

---

一、标题解释与读者心智锚定

（一）标题拆解

你没看错——100 行左右可运行、可扩展的 Python 代码，就能搞定从日历查询、参会人协调、会议室匹配到最终生成并发送 Google Calendar 邀请的完整流程。而且这不是一个“玩具脚本”，而是基于 Agent Harness Engineering（Agent 工程化骨架开发） 理念构建的轻量级生产级预研骨架。

这里的 Agent Harness Engineering 是我整合最近热门的 Agent DevOps化、工具调用标准化、状态管理轻量化 提出的概念：核心是先搭一套“骨架系统”（相当于 Harness 之于 CI/CD），处理调度、状态流转、工具抽象、错误兜底这些非业务逻辑的通用脏活累活，业务逻辑（比如查日历、选会议室）则通过标准化的钩子（Hooks）或插件（Plugins）灵活挂载——骨架代码通常控制在 100-200 行，保证可读性和可测试性的同时，支持快速迭代。

（二）读者心智锚定

如果你是：

1. 刚入门 AI Agent 的 Python 开发者：不想被 LangChain 的复杂模块、AutoGPT 的混乱代码劝退，想从“最小可行性骨架”理解 Agent 的本质；
2. 需要快速验证自动化办公场景的产品经理/测试工程师：100 行代码就能搭出可演示的原型，甚至可以直接对接内部系统（把 Google 工具换成飞书/钉钉/企业微信就行）；
3. 对 DevOps 理念感兴趣的 AI 工程师：想把 CI/CD 的“可观测、可扩展、可回滚”思想用到 Agent 开发上。

那这篇文章绝对是你的菜——我们不会先讲一堆没用的理论，而是直接从「你要解决什么问题」「怎么用 100 行搭骨架」「怎么扩展业务逻辑」「怎么优化生产落地」四个维度，把这个会议预订 Agent 从 0 到 100% 落地。

---

二、摘要/引言：为什么要做这个自动预订会议的 AI Agent？

（一）开门见山：一个程序员的“会议焦虑症”真实写照

上周，我帮项目组协调了 11 次跨时区跨部门会议，总共花了 12 小时 47 分钟——这还不算事后修改时间重发邀请的时间。以下是我那天的“惨痛”聊天记录截图（脱敏处理）：

（这里可以放一张模拟的微信/飞书/Teams 聊天截图，核心内容是：

1. 小明：下周一下午3点有空吗？
2. 小红：不行，要见客户；那周二上午10点？
3. 小刚：我在洛杉矶，周二上午10点是我凌晨1点；
4. 小李：我要参加另外一个会；
5. 还有会议室，301上周刚装修，302投影坏了，201需要提前申请设备……
6. 最后，好不容易协调了周三下午4点（小刚是周三凌晨0点？哦不对要算好UTC+8和UTC-8的时差，比如改成周三上午10点（我是UTC+8，小明小红也是；小刚是UTC-8周二下午6点），会议室用202，投影好，不需要设备，可容纳6人））

（二）问题陈述：人工协调会议的三大核心痛点

通过那次“惨痛”经历，我总结出人工协调会议的三大不可避免的核心痛点：

1. 参会人协调效率极低：跨时区跨部门的情况下，往往需要“试错式”协调——先问A的时间，再问B，再问C，一旦C不行，前面的都白问；更别说还要处理“忙/闲”之外的「软约束」（比如小刚不想凌晨2点以后开会，小红需要提前30分钟结束接孩子）。
2. 会议室匹配容易出错：要手动查会议室的「硬约束」（容量、设备、位置、装修状态）和「软约束」（比如301是给高管预留的，除非特别申请；202是给产品组预留的），一不小心就会订错。
3. 全流程无自动化兜底：协调好时间和会议室后，要手动写会议主题、参会人列表、会议地点、会议链接（如果是线上线下混合的）、会议纪要提醒，甚至要手动算时区转换；如果有人临时取消或修改时间，还要重新协调，重新发邀请。

（三）核心价值：这个100行代码的Agent能帮你做什么？

我们这个基于 Agent Harness Engineering 的会议预订 Agent，能完全自动化解决上面的三大核心痛点——而且只用了 100 行左右的骨架代码！具体来说，它能：

1. 智能理解用户需求：不用你填复杂的表单，只要用自然语言说一句（或者发一段文字）：“帮我订一个下周三之前的、可容纳6人的、有投影的、在2楼的会议室，参会人是小明、小红、小刚（在洛杉矶），会议主题是‘XX项目Q3技术评审’，时长1小时，大家尽量不要在凌晨1点以后（小刚）和下午4点以后（小红）开会”，它就能自动解析出所有的硬约束和软约束。
2. 自动协调参会人时间：它会先查询所有参会人的公开日历忙闲状态，再结合软约束筛选出「候选时间窗口」，最后还会优先级排序（比如优先选大家都精神饱满的时间，比如我和小明小红的上午10-11点，也就是小刚的前一天下午6-7点）。
3. 自动匹配会议室：它会自动查询会议室管理系统的可用状态，再结合硬约束（容量、投影、2楼）和软约束（不是高管预留，不是产品组预留——哦不对用户没说，但我们可以在骨架里加个默认软约束插件）筛选出「候选会议室」，最后优先级排序（比如优先选距离我们部门最近的202，其次是203）。
4. 自动生成并发送邀请：它会自动生成会议主题、参会人列表、会议地点、会议链接（我们可以用Google Meet，或者换成Zoom、飞书会议、钉钉会议）、会议纪要提醒（提前24小时发邮件给所有参会人）、时区转换说明（给小刚单独发一段UTC-8的时间），最后一键发送 Google Calendar 邀请（或者换成飞书/钉钉/企业微信日程）。
5. 自动处理异常情况：如果候选时间窗口和候选会议室都没有交集，它会自动给你发一个“异常报告”，列出“可能的备选方案”（比如减少参会人、缩短会议时长、换其他楼层的会议室、或者调整小刚的软约束到凌晨0点-1点之间）；如果有人临时取消或修改时间，它会自动重新协调（不过这个功能我们会在「边界与外延」和「最佳实践」里讲，因为100行骨架代码主要处理“首次预订”的核心流程）。

（四）文章概述：接下来我们会讲什么？

为了让你从零到 100% 理解并落地这个会议预订 Agent，我们将按照以下结构来讲解：

1. Agent Harness Engineering 核心概念：我们会先补全这个概念的定义、背景、核心要素组成、边界与外延，以及和其他 Agent 开发框架（比如 LangChain、AutoGPT、AutoGen）的对比——虽然我们用的是自己的轻量级骨架，但对比这些主流框架能帮你更好地理解“骨架开发”的优势。
2. 自动预订会议的 AI Agent 核心需求拆解：我们会把刚才的自然语言需求，拆解成「技术需求」「业务需求」「非功能需求」——这是构建任何系统的第一步，也是最重要的一步。
3. 核心技术选型与环境安装：我们会选择最少但最实用的技术栈：Python 3.10+、OpenAI GPT-4o Mini（或者 GPT-3.5 Turbo，成本更低）、Google Calendar API（或者换成飞书/钉钉/企业微信的日程API）、Google Workspace Admin SDK Directory API（用来查参会人邮箱对应的时区和部门，可选）、Python 标准库的 datetime、pytz（时区转换，可选，Python 3.9+ 有 zoneinfo）、tenacity（重试机制，可选，但生产级需要）——环境安装我们会用 pip 和 virtualenv（或者 conda，任选），保证可复现。
4. 100 行左右的 Agent Harness 骨架代码实现：这是文章的核心部分——我们会一行一行地解释代码，包括「状态管理」「工具抽象」「工具调用调度」「错误兜底」「自然语言需求解析」这五个核心模块——保证你能看懂，而且能自己修改。
5. 业务逻辑插件实现：我们会实现四个核心业务逻辑插件：「自然语言需求解析插件」「参会人日历查询插件」「会议室查询插件」「Google Calendar 邀请生成插件」——这些插件代码简单，但完全符合 Agent Harness Engineering 的“标准化钩子”理念。
6. 实际场景测试与演示：我们会用刚才的自然语言需求来测试这个 Agent，看看它能不能正确解析需求、协调时间、匹配会议室、生成并发送邀请——我们会放真实的测试截图和日志输出。
7. 边界与外延：这个 Agent 能做什么？不能做什么？怎么扩展？：我们会明确这个 100 行骨架代码的边界，然后讲怎么扩展它（比如对接飞书/钉钉/企业微信、处理临时取消/修改时间、增加软约束优先级、增加多轮对话、增加可观测性、增加安全性）。
8. 最佳实践 Tips：如何把这个 Agent 从“预研原型”变成“生产级系统”？：我们会分享 10 个左右的生产级最佳实践，包括「API 密钥管理」「重试机制」「限流与降级」「数据隐私保护」「可观测性」「测试」「部署」「监控」「迭代」。
9. 行业发展与未来趋势：Agent Harness Engineering 的过去、现在和未来：我们会用一个表格梳理 Agent 开发理念的演变发展历史，然后讲 Agent Harness Engineering 的未来趋势（比如 Agent 编排、Agent 市场、Agent 联邦学习）。
10. 本章小结与行动号召：我们会简要回顾文章的主要内容，然后鼓励你尝试自己修改这个 Agent，甚至可以对接自己的内部系统——最后我们会留一个开放性问题，邀请你在评论区分享你的想法或问题。

---

三、Agent Harness Engineering 核心概念

在开始写代码之前，我们先花点时间搞懂 Agent Harness Engineering——因为只有理解了理念，你才能真正用好这个 100 行的骨架代码，而不是只会“复制粘贴”。

（一）核心概念：什么是 Agent Harness Engineering？

1. 定义

Agent Harness Engineering（Agent 工程化骨架开发） 是一种以「可观测、可扩展、可回滚、轻量级」为核心的 AI Agent 开发理念，它的核心思想是：

先搭一套通用的、标准化的、可复用的骨架系统（Harness），处理所有非业务逻辑的通用脏活累活（比如状态管理、工具抽象、工具调用调度、错误兜底、API 密钥管理、日志记录、可观测性）；业务逻辑（比如查日历、选会议室、写邮件、订机票）则通过标准化的钩子（Hooks）或插件（Plugins）灵活挂载，不需要修改骨架代码；整个系统的代码结构清晰，可读性和可测试性极高，骨架代码通常控制在 100-200 行，业务逻辑插件可以随时添加、删除或替换。

2. 类比：把 Agent Harness 比作汽车的“底盘”

为了让你更好地理解这个概念，我们可以用一个通俗易懂的汽车类比：

• Agent Harness（骨架系统） 就是汽车的底盘——它包含了发动机舱、变速箱、悬挂系统、刹车系统、转向系统、电气系统这些通用的、标准化的、可复用的核心部件，决定了汽车的“安全性、可靠性、可扩展性”（比如你可以在同一套底盘上装不同的发动机、变速箱、车身、轮胎，做成轿车、SUV、MPV 等不同的车型）；
• 业务逻辑插件（Plugins） 就是汽车的车身、轮胎、座椅、音响、导航系统——它们是特定场景的、可灵活替换的部件，决定了汽车的“功能、外观、舒适度”（比如你可以把导航系统从 Google Maps 换成高德地图，把音响从 Bose 换成哈曼卡顿，把轮胎从四季胎换成雪地胎，不需要修改底盘）；
• 开发者 就是汽车的改装师——他们只需要根据自己的需求，在同一套底盘上改装不同的车身、轮胎、座椅、音响、导航系统，就能做出符合自己需求的汽车，不需要从零开始设计和制造底盘。

（二）问题背景：为什么需要 Agent Harness Engineering？

1. 当前主流 Agent 开发框架的痛点

要理解为什么需要 Agent Harness Engineering，我们先看看当前主流的 Agent 开发框架（LangChain、AutoGPT、AutoGen）存在的痛点：

• LangChain：功能非常强大，模块非常多（Chains、Agents、Tools、Memory、Vector Stores、LLMs、Prompts 等），但代码结构非常复杂，学习曲线非常陡峭——刚入门的开发者往往会被这些模块吓到，不知道从哪里开始；而且 LangChain 的代码更新非常快，经常有 breaking changes，维护成本很高；另外，LangChain 的“开箱即用”的 Agent 往往不够灵活，很难满足特定场景的需求。
• AutoGPT：曾经非常火，是第一个“自主 AI Agent”的代表，但代码结构非常混乱，没有明确的架构设计——很难维护和扩展；而且 AutoGPT 非常“任性”，经常会做出一些不可预测的事情（比如花光你的 OpenAI API 额度，或者访问一些不安全的网站），安全性和可控性很差；另外，AutoGPT 的效率非常低，往往需要几十次甚至几百次 LLM 调用才能完成一个简单的任务。
• AutoGen：Microsoft 推出的多 Agent 协作框架，功能也非常强大，但代码结构也比较复杂，主要针对多 Agent 协作场景——对于单 Agent 场景（比如我们的会议预订 Agent）来说，有点“杀鸡用牛刀”；而且 AutoGen 的学习曲线也比较陡峭，刚入门的开发者很难快速上手。

2. 预研原型到生产级系统的“断崖式差距”

除了主流框架的痛点之外，很多开发者还遇到过预研原型到生产级系统的“断崖式差距”：

• 预研原型的时候，你可能用了 50 行 Python 代码，调用了 OpenAI API 和一个简单的工具，就做出了一个看起来不错的原型；
• 但要把这个原型变成生产级系统，你需要加很多东西：API 密钥管理、重试机制、限流与降级、数据隐私保护、日志记录、可观测性、测试、部署、监控、迭代……
• 这些东西加起来，代码可能从 50 行变成了 5000 行，而且代码结构变得非常混乱，很难维护和扩展。

3. DevOps 理念在 AI 领域的渗透

最近几年，DevOps 理念（可观测、可扩展、可回滚、持续集成、持续部署）已经从传统的软件领域渗透到了 AI 领域——很多 AI 工程师开始意识到，AI 系统（尤其是 AI Agent 系统）和传统的软件系统一样，也需要“可观测、可扩展、可回滚、持续集成、持续部署”；而 Agent Harness Engineering 就是 DevOps 理念在 AI Agent 开发领域的具体体现。

（三）核心要素组成：Agent Harness Engineering 的五个核心模块

一个完整的 Agent Harness 骨架系统，通常包含以下五个核心模块：

1. 状态管理模块（State Management）：负责管理 Agent 的整个生命周期的状态（比如「初始状态」「需求解析状态」「工具调用状态」「结果生成状态」「异常状态」「结束状态」），保证 Agent 的状态流转是可预测、可观测、可回滚的。
2. 工具抽象模块（Tool Abstraction）：负责把所有的工具（比如 Google Calendar API、Google Maps API、飞书日程 API、数据库查询 API、HTTP 请求 API）抽象成标准化的接口（比如 Tool 基类，包含 name、description、parameters、run 四个核心属性/方法），保证工具的调用是统一的、可复用的、可替换的。
3. 工具调用调度模块（Tool Call Orchestration）：负责根据 Agent 的当前状态和 LLM 的输出，智能调度工具的调用——包括选择要调用的工具、解析工具的参数、执行工具的调用、处理工具的返回结果、把结果反馈给 LLM。
4. 错误兜底模块（Error Handling & Fallback）：负责处理 Agent 运行过程中可能出现的所有异常情况（比如 LLM API 调用失败、工具 API 调用失败、参数解析错误、没有候选时间窗口、没有候选会议室）——包括重试机制、降级机制、异常报告生成、用户反馈收集。
5. 日志记录与可观测性模块（Logging & Observability）：负责记录 Agent 运行过程中的所有关键信息（比如当前状态、LLM 的输入输出、工具的调用参数和返回结果、异常情况的详细信息），保证 Agent 的运行是可观测、可调试、可监控的。

为了让你更好地理解这五个核心模块的关系，我们画了一个 ER 实体关系图（Mermaid 架构图）：

除了 ER 实体关系图之外，我们还画了一个 Agent Harness 与业务逻辑插件的交互关系图（Mermaid 架构图）：

（四）概念之间的关系：Agent Harness Engineering vs 主流 Agent 开发框架

为了让你更好地理解 Agent Harness Engineering 和其他主流 Agent 开发框架的区别，我们做了一个 概念核心属性维度对比的 Markdown 表格：

核心属性维度	Agent Harness Engineering	LangChain	AutoGPT	AutoGen
核心理念	先搭通用骨架，业务逻辑通过插件灵活挂载	链式调用 LLM 和工具，提供开箱即用的 Agent 模板	自主 AI Agent，无明确目标限制，自主探索和执行任务	多 Agent 协作，通过对话和工具调用完成复杂任务
代码结构	非常清晰，骨架代码 100-200 行，业务逻辑插件独立	比较复杂，模块非常多，代码量大	非常混乱，没有明确的架构设计，代码量大	比较复杂，主要针对多 Agent 场景，代码量大
学习曲线	非常平缓，刚入门的开发者 1-2 小时就能上手	比较陡峭，刚入门的开发者需要 1-2 周才能熟练掌握	中等，但可控性很差，很难调试	比较陡峭，刚入门的开发者需要 1-2 周才能熟练掌握
灵活性	非常高，业务逻辑插件可以随时添加、删除或替换，不需要修改骨架代码	中等，开箱即用的 Agent 模板不够灵活，需要自定义 Chains 和 Agents	非常高，但可控性很差，很难预测 Agent 的行为	高，主要针对多 Agent 协作场景，可以自定义 Agent 的角色和行为
可控性	非常高，状态管理明确，工具调用可观测，错误兜底完善	中等，有状态管理和工具调用调度，但代码更新快，breaking changes 多	非常低，没有明确的状态管理，工具调用不可预测，错误兜底不完善	中等，有状态管理和多 Agent 对话调度，但主要针对多 Agent 场景
可观测性	非常高，骨架代码内置日志记录和可观测性模块，所有关键信息都可追踪	中等，有日志记录模块，但需要自定义可观测性模块	非常低，几乎没有可观测性模块，很难调试	中等，有日志记录模块，但需要自定义可观测性模块
生产级适用性	非常高，骨架代码内置 API 密钥管理、重试机制、限流与降级、数据隐私保护等生产级功能	中等，有一些生产级功能，但需要大量的自定义和优化	非常低，几乎没有生产级功能，只能用于预研原型	中等，有一些生产级功能，但主要针对多 Agent 场景，需要大量的自定义和优化
更新频率	非常低，骨架代码一旦稳定，就不会频繁更新，业务逻辑插件可以独立更新	非常高，几乎每周都有更新，经常有 breaking changes	低，最近更新很少	中等，每月都有更新
维护成本	非常低，骨架代码清晰，业务逻辑插件独立，维护起来很容易	比较高，代码更新快，breaking changes 多，维护起来比较困难	非常高，代码结构混乱，维护起来非常困难	比较高，代码更新快，主要针对多 Agent 场景，维护起来比较困难

（五）边界与外延：Agent Harness Engineering 能做什么？不能做什么？

1. 边界：Agent Harness Engineering 的适用场景

Agent Harness Engineering 主要适用于以下场景：

• 单 Agent 自动化任务场景：比如自动预订会议、自动写邮件、自动订机票、自动整理会议纪要、自动爬取数据、自动生成报告等——这些场景通常有明确的目标、明确的步骤、明确的工具需求，不需要多 Agent 协作。
• 预研原型快速验证场景：比如你想快速验证一个 AI Agent 的想法，不需要复杂的功能，只需要核心流程——Agent Harness Engineering 的 100-200 行骨架代码，加上几个简单的业务逻辑插件，就能在 1-2 小时内做出一个可演示的原型。
• 生产级系统快速落地场景：比如你已经有了一个预研原型，想把它变成生产级系统——Agent Harness Engineering 的骨架代码已经内置了 API 密钥管理、重试机制、限流与降级、数据隐私保护、日志记录、可观测性等生产级功能，你只需要把预研原型的业务逻辑代码改成标准化的插件，就能快速落地。

2. 边界：Agent Harness Engineering 的不适用场景

Agent Harness Engineering 主要不适用于以下场景：

• 多 Agent 复杂协作场景：比如多人在线游戏的 AI 队友、多部门协作的项目管理 AI、多模型协作的 AI 研究平台——这些场景需要复杂的多 Agent 对话调度、角色分配、任务分解、结果整合，Agent Harness Engineering 的单 Agent 骨架代码无法满足需求，这时候应该用 AutoGen 或者其他多 Agent 协作框架。
• 无明确目标的自主探索场景：比如自动探索互联网、自动研究一个新领域、自动生成新的创意——这些场景需要无明确目标限制的自主 AI Agent，Agent Harness Engineering 的明确状态管理和工具调用调度无法满足需求，这时候应该用 AutoGPT 或者其他自主 AI Agent 框架（但要注意可控性和安全性）。
• 超大规模的 AI Agent 平台场景：比如类似于 OpenAI GPTs Store、LangChain LangSmith 这样的超大规模 AI Agent 平台——这些场景需要复杂的 Agent 编排、Agent 市场、Agent 联邦学习、Agent 安全审计等功能，Agent Harness Engineering 的轻量级骨架代码无法满足需求，这时候应该用更复杂的 AI Agent 平台框架。

3. 外延：Agent Harness Engineering 的扩展方向

虽然 Agent Harness Engineering 有明确的边界，但它的扩展性非常强——你可以通过以下几个方向扩展它：

• 对接多 Agent 协作框架：比如把 Agent Harness 作为 AutoGen 中的一个“单 Agent 组件”，这样你就可以用 AutoGen 的多 Agent 协作能力，结合 Agent Harness 的单 Agent 轻量级、高可控性、高可观测性能力，完成复杂的多 Agent 协作任务。
• 对接 Agent 编排框架：比如把 Agent Harness 作为 Airflow、Prefect、Dagster 这样的工作流编排框架中的一个“任务节点”，这样你就可以用工作流编排框架的任务调度、依赖管理、重试机制、监控能力，结合 Agent Harness 的单 Agent 能力，完成复杂的工作流任务。
• 对接 Agent 市场：比如把你用 Agent Harness 开发的业务逻辑插件，发布到类似于 OpenAI GPTs Store、LangChain LangChain Hub 这样的 Agent 市场，这样其他开发者就可以直接使用你的插件，不需要自己重新开发。
• 增加多轮对话能力：比如在 Agent Harness 的状态管理模块中，增加“对话历史”的状态，这样 Agent 就可以记住之前的对话内容，和用户进行多轮对话，处理更复杂的需求。
• 增加可观测性平台对接：比如在 Agent Harness 的日志记录与可观测性模块中，增加对 Prometheus、Grafana、Jaeger、OpenTelemetry 这样的可观测性平台的对接，这样你就可以更直观地监控 Agent 的运行状态、性能指标、错误情况。
• 增加安全性功能：比如在 Agent Harness 的工具抽象模块中，增加“工具权限管理”的功能，在错误兜底模块中，增加“异常安全审计”的功能，在日志记录与可观测性模块中，增加“敏感数据脱敏”的功能，这样你就可以保证 Agent 的安全性，防止 Agent 做出一些不可预测的事情（比如访问不安全的网站、泄露敏感数据、花光你的 API 额度）。

---

四、自动预订会议的 AI Agent 核心需求拆解

在开始写代码之前，我们先把刚才的自然语言需求，拆解成技术需求、业务需求、非功能需求——这是构建任何系统的第一步，也是最重要的一步。

（一）原始自然语言需求

我们用以下这个最典型的跨时区跨部门会议预订需求作为原始需求：

“帮我订一个下周三之前（包含下周三）的、可容纳6人的、有投影的、在2楼的会议室，参会人是小明（xiaoming@example.com）、小红（xiaohong@example.com）、小刚（xiaogang@example.com，在洛杉矶，UTC-8），会议主题是**‘XX项目Q3技术评审’，时长1小时**，大家尽量不要在凌晨1点以后（小刚，当地时间）和下午4点以后（小红，当地时间，UTC+8）开会，会议地点在我们公司的2楼会议室，会议链接用Google Meet，提前24小时发邮件给所有参会人提醒会议纪要准备，给小刚单独发一段UTC-8的时间说明。”

（二）业务需求拆解

我们把原始自然语言需求，拆解成以下10个明确的业务需求：

1. 需求解析：能够从自然语言需求中，自动解析出所有的硬约束和软约束——包括时间范围、参会人列表、参会人时区、参会人软约束、会议室硬约束、会议室软约束、会议主题、会议时长、会议地点、会议链接类型、会议提醒时间、特殊说明。
2. 参会人信息获取：能够从Google Workspace Admin SDK Directory API（或者从内部数据库）中，自动获取参会人邮箱对应的真实姓名、部门、默认时区——如果用户已经提供了时区（比如小刚的UTC-8），则用用户提供的时区，否则用默认时区。
3. 参会人日历查询：能够从Google Calendar API中，自动查询所有参会人在指定时间范围内的公开日历忙闲状态——注意只能查询公开日历，不能查询私人日历，保护用户隐私。
4. 候选时间窗口筛选：能够根据所有参会人的公开日历忙闲状态和软约束，自动筛选出「候选时间窗口」——要求所有参会人都在忙闲状态的“闲”，并且满足所有参会人的软约束。
5. 候选时间窗口优先级排序：能够根据预设的优先级规则，对候选时间窗口进行优先级排序——比如优先选大家都精神饱满的时间（比如我和小明小红的上午10-11点，也就是小刚的前一天下午6-7点），其次选上午9-10点和下午2-3点，最后选其他时间。
6. 会议室信息获取：能够从会议室管理系统API（或者从内部数据库，我们这里用一个模拟的会议室数据库）中，自动获取所有会议室的信息——包括会议室名称、位置、容量、设备、装修状态、预留部门、可用状态。
7. 候选会议室筛选：能够根据会议室的硬约束和软约束，自动筛选出「候选会议室」——要求会议室在指定时间范围内的候选时间窗口内是“可用”的，并且满足所有的硬约束和软约束。
8. 候选会议室优先级排序：能够根据预设的优先级规则，对候选会议室进行优先级排序——比如优先选距离我们部门（产品技术部，假设在2楼东侧）最近的202，其次是203（2楼东侧），最后是201（2楼西侧）。
9. 会议邀请生成与发送：能够从优先级最高的候选时间窗口和候选会议室中，自动生成会议邀请——包括会议主题、参会人列表、会议地点、会议链接（Google Meet）、会议开始时间（UTC+8和UTC-8）、会议结束时间（UTC+8和UTC-8）、会议提醒时间（提前24小时发邮件）、特殊说明（给小刚单独发UTC-8的时间说明）——然后一键发送 Google Calendar 邀请。
10. 最终结果反馈：能够把最终的预订结果（包括会议开始时间、会议结束时间、会议地点、会议链接、参会人列表），用自然语言反馈给用户。

（三）技术需求拆解

我们把业务需求，拆解成以下8个明确的技术需求：

1. LLM 调用：能够调用OpenAI GPT-4o Mini（或者 GPT-3.5 Turbo），用于自然语言需求解析、候选时间窗口和候选会议室的选择、最终结果的自然语言反馈。
2. Google Calendar API 调用：能够调用Google Calendar API v3，用于查询参会人的公开日历忙闲状态、生成并发送 Google Calendar 邀请。
3. Google Workspace Admin SDK Directory API 调用（可选）：能够调用Google Workspace Admin SDK Directory API v1，用于获取参会人邮箱对应的真实姓名、部门、默认时区——如果没有 Google Workspace 账号，可以用一个模拟的数据库代替。
4. 时区转换：能够处理不同时区的时间转换——比如把 UTC+8 的时间转换成 UTC-8 的时间，把本地时间转换成 UTC 时间（存储和查询用 UTC 时间，展示用本地时间）。
5. JSON Schema 解析：能够生成和解析JSON Schema，用于 LLM 的工具调用参数约束——保证 LLM 生成的工具调用参数是符合要求的。
6. 状态管理：能够管理 Agent 的整个生命周期的状态——包括「初始状态」「需求解析状态」「参会人信息获取状态」「参会人日历查询状态」「候选时间窗口筛选状态」「候选会议室筛选状态」「会议邀请生成状态」「异常状态」「结束状态」。
7. 错误兜底：能够处理 Agent 运行过程中可能出现的所有异常情况——包括 LLM API 调用失败、Google Calendar API 调用失败、参数解析错误、没有候选时间窗口、没有候选会议室、候选时间窗口和候选会议室没有交集。
8. 日志记录：能够记录 Agent 运行过程中的所有关键信息——包括当前状态、LLM 的输入输出、工具的调用参数和返回结果、异常情况的详细信息。

（四）非功能需求拆解

除了业务需求和技术需求之外，我们还有以下5个明确的非功能需求：

1. 轻量级：整个系统的代码量（骨架代码 + 业务逻辑插件代码）应该控制在 300 行以内——骨架代码控制在 100 行左右。
2. 可扩展性：业务逻辑插件应该可以随时添加、删除或替换——不需要修改骨架代码。
3. 高可控性：Agent 的状态流转应该是可预测的——所有的工具调用都应该是明确的，没有自主探索。
4. 高可观测性：Agent