509e266626
后端： 1. 工具执行结果协议升级为结构化 ToolExecutionResult——execute/tool_runtime、ToolRegistry、stream extra 与 timeline 持久化统一改为透传 observation_text / summary / argument_view / result_view，不再只回写纯文本结果；context_tools、upsert_task_class 与旧 schedule/web 工具通过兼容包装接入新协议 2. 日程写工具注册继续收口——place / move / swap / batch_move / unplace / queue_apply_head_move 从 registry 内联实现下沉为独立 handler，降低注册表内参数解析与业务逻辑混写 3. 工具结果展示基础能力补齐——新增 execution_result / schedule_operation_handlers 公共件，为日程操作结果、参数本地化展示、blocked/failed/done 状态统一建模 前端： 4. AssistantPanel 接入结构化工具卡片渲染——新增 ToolCardRenderer，tool_call / tool_result 支持 argument_view / result_view 展示；schedule_completed 恢复为时间线内的占位卡片块，避免排程卡片脱离原消息顺序 5. 时间线类型与渲染收敛——schedule_agent.ts 补齐 ToolView 协议，AssistantPanel 改为按块渲染 tool / schedule_card / business_card，并移除旧 demo/prototype 路由与页面，收束正式面板代码路径 仓库： 6. AGENTS.md 新增协作约束——禁止擅自回滚、覆盖或删除用户/其他代理产生的工作区改动
4.1 KiB
4.1 KiB
AGENTS.md
协作偏好（逐条追加）
- 默认语言规则：所有注释、接口文案、说明、评审反馈均使用中文。
- 请勤加注释，尤其是复杂逻辑部分，确保代码易于理解和维护。
- 每次在本地执行测试命令（如
go test）后，必须清理项目根目录下的.gocache目录，避免缓存文件长期堆积。 - 文件编码统一使用 UTF-8（无 BOM），禁止使用 GBK、GB2312 等其他编码，避免中文内容出现乱码。
- 进行结构重构时，优先采用“并行迁移”策略：允许新旧目录并存，先迁移、再切流、再验证、最后删除旧实现，禁止一步到位式重命名大改。
- 遇到公共能力（如模型调用、JSON 解析、阶段推送、深拷贝、缓存快照读写）时，若在第二处出现重复实现，必须优先评估是否抽公共层，禁止无脑复制第三份。
- 迁移期每一轮只允许处理一个能力域或一类公共件，禁止同一轮同时改多个 skill 的结构与逻辑，避免回归问题无法定位。
- 新增代码时，必须优先复用已有公共能力；如果暂时无法复用，必须在注释或文档中写明“为什么这次不能抽公共层”，禁止默认复制粘贴旧实现。
- 对于明显过大的文件（尤其是同时承载编排、业务、模型交互、工具分发的文件），后续重构时必须拆分职责，禁止继续向单文件堆砌新逻辑。
- Prompt、State、模型交互、Graph 连线应尽量分目录/分文件管理，禁止把大段 prompt、节点逻辑、模型 helper 长期混写在同一文件中。
- 若本轮任务包含“结构迁移”，最终答复中必须明确说明：本轮迁了什么、哪些旧实现仍保留、当前切流点在哪里、下一轮建议迁什么。
- 若后续在
backend/agent中新增、下沉、替换任何“通用能力”，必须同步更新backend/agent/通用能力接入文档.md，否则视为重构信息不完整。 - 写完代码后，如果输入输出格式明确、逻辑可验证（如数据转换函数、解析函数、工具层操作），必须编写单元测试验证正确性。跑完之后删除测试文件（
*_test.go），禁止把测试文件长期留在项目中。 - 当 Claude Code 帮助操作 git 提交时，commit message 中禁止出现与 Claude 协同相关的描述（如 Co-Authored-By 等），只保留项目本身的内容。
- 实现任何 Eino 新功能之前，必须先阅读 Eino 官方文档并确认对应能力的推荐接入方式与参数语义，禁止在未查文档的情况下直接编码。
- 禁止擅自回滚、覆盖、删除工作区内由用户或其他代理产生的改动；若发现无关改动影响当前任务，必须先说明风险并征得明确同意后再处理。
注释规范（强制）
- 默认使用中文注释，禁止英文注释（专业术语除外）。
- 复杂逻辑必须写“步骤化注释”，用
1. / 2. / 2.1这种编号，说明：- 这一步要做什么
- 为什么要这样做
- 失败时怎么处理
- 兜底/回退策略是什么
- 函数注释至少说明“职责边界”：
- 这个函数负责什么
- 不负责什么
- 输入输出语义（尤其是 bool、error、状态字段）
- 涉及分支、重试、事务、幂等、并发、状态机的代码，必须写清楚判断依据与流转条件。
- 跨文件调用前必须写“调用目的注释”，让读者不跳转文件也能理解当前代码意图。
- 注释禁止空话（如“设置变量”“调用方法”）；必须写业务意图与约束。
- 改动代码时，如修改了复杂逻辑，必须同步更新注释；注释过期视为不合格提交。
- 不要求每行都注释；简单直白代码可省略，重点保证关键路径可读性。
注释风格示例
推荐：
// 1. 先查缓存，命中则避免回源 DB，降低接口延迟。// 2. 缓存未命中再查库；若查库失败直接返回，避免写入不完整状态。// 3. 写库成功后再更新缓存，保证“先真后快”，避免脏缓存。
不推荐：
// 查询缓存// 调用 DAO// 返回结果