JianFeeeee
5b76ac5c57
feat(homeagent): 四个日程工具 + 工具计数不再硬编码
create_schedule / list_schedules / update_schedule / delete_schedule，
插件从 11 个工具变 15 个。
时间格式是这组工具最容易出错的地方，parseEventTime 接受三种形态：
完整 RFC3339（推荐）、无时区（按本机时区解释）、只有日期（当天 9 点，
比零点有用 —— 零点的提醒没人看）。
**刻意不接受自然语言**（「明天九点」）：解析它需要知道模型以为今天是哪天，
而它上下文里那个日期常常是错的 —— 一个静默偏移一天的提醒比报错糟得多。
解析失败的报文里带上当前本机时间，让它能自己算。
其他细节：
- recipients 用逗号分隔的 string 而非数组：几个平台对数组参数的 schema
支持不一致，而逗号分隔在所有平台上都是普通 string。中英文逗号都收 ——
中文输入法下打出「，」是常态。
- argInt 同时收 float64 与字符串："30" 带引号会让「提前 30 分钟」静默失效。
- update 的工具描述里写明「只传要改的字段」：模型的默认倾向是回传它记得的
全部字段，记错一个就覆盖掉原有的提醒正文或收件方。
- list 在接近上限（>=75%）时主动提示清理，而不是等撞墙 —— 撞墙那一刻
模型往往正在做别的事，没有余裕去清理。
- scheduleEvent.effectiveRecipients() 与服务端同一条兜底链：只读
recipients 会让旧数据显示成「发给：」后面空白。
**工具计数从 RegisterTool 的调用数派生，不硬编码。**
之前写死 13 而实际注册 11 —— 排查「工具没生效」时日志说 13、平台说 11，
两个数字都不可信，白花了一轮时间。加工具时忘改常量是必然的，
所以让它没有机会写错。
plugin.go 另补 put/delete 两个 HTTP 辅助（原来只有 get/post）。
已部署验证：homed 日志「注册完成（15 个工具 + 1 个输出通道）」，
模型实际调用 list_schedules 成功。
2026-09-04 06:28:55 +08:00
..
2026-09-03 21:10:48 +08:00
2026-09-04 06:28:55 +08:00
2026-09-03 21:10:48 +08:00
2026-09-03 21:11:15 +08:00