$ incident: order-service 14:20 大量 500
- 01接到报错 / 需求确定服务名和问题范围输入
- 02翻项目 Wiki查历史方案与负责人文档
- 03查 API 字段与示例确认参数与版本接口
- 04筛日志、定位 Error聚合时间范围与堆栈日志
- 05梳理调用链再判断最后才决定是否能修改依赖
● INTERNSHIP PROJECT · TOOL CALLING
开发者提效 Agent
面向游戏 UGC 与小游戏研发的内部开发场景，把查 API、找文档、看日志、定位 Error 等重复任务拆成可解释、可确认、可回退的工具链。
30+可调用工具能力
10+知识资产类型
8 个典型开发任务
5 名内部试用开发者
约 160 分钟 → 60 分钟八项任务总耗时
约 -65%典型任务耗时降幅
口径：从开发者开始查找任务相关资料，到获得可执行的定位结论、修复建议或写入操作预览为止；不包含真实生产发布后的长期验证时间。
开发者需要的不是“更多答案”，而是少一点无效上下文切换。
高频问题横跨项目 Wiki、API 文档、服务日志、调用链与历史案例。人可以跨来源补齐上下文，但每次排查都要重新定位、筛选与判断是否能操作。
INPUTorder-service · 14:20 · 500 Error
+++
Agent 负责识别问题范围 → 并行检索资料 → 调用分析工具 → 解释结果每个结论保留工具来源、输入条件与待确认项。
WRITE GATE涉及写入时：预览影响 → 人工确认 → 执行 / 回退
Tool Calling 的重点不是调用数量，而是知道什么可以直接做。
将 30+ 能力按执行风险分层，避免把“能查到”误变成“能直接改”。
读取已有资料，不改变任何系统状态。
必须标明信息来源、置信情况和待确认条件。
先展示影响范围与回退方式，再由用户授权执行。
{
"service": "order-service", // required
"timeRange": "14:15-14:30", // required
"traceId": "optional",
"level": "ERROR"
}
用途聚合指定服务、时间范围内的错误调用链返回错误摘要、关键堆栈、关联服务与 Trace ID失败状态参数缺失 / 无权限 / 日志服务超时
为什么需要这些参数？
服务名限定检索边界，避免在全量日志里得到噪声。
时间范围把“14:20 开始大量 500”转成可查询条件。
Trace ID不是必填，但有它时才能串起跨服务调用。
工具卡可点击切换，展示查询、分析和写入工具的不同定义。
参数缺失：阻断并提示补充权限不足：展示授权范围调用失败：保留上下文并重试不可逆写入：必须二次确认
从一条“14:20 大量 500”开始，把工具调用过程变成可追溯的排查链路。
Demo 用脱敏的 order-service 场景说明：Agent 并不是直接输出结论，而是按日志、调用链、文档和写入确认依次补齐判断。
评测验证的是“同一任务能否更快走完”，而不是回答看起来是否聪明。
样本范围5 名内部开发人员，围绕 8 个高频任务进行流程级测试
计时范围从开始查找任务上下文，到形成定位结论、修复建议或写入预览
判定标准结果是否可追溯、工具调用是否符合权限边界、是否需要人工确认
结果口径8 项任务总耗时约 160 分钟降至约 60 分钟，降幅约 65%
典型任务原耗时Agent 后结果差异原因
查询 API 字段与示例18 分钟7 分钟可直接完成减少跨文档检索
定位 order-service 50035 分钟12 分钟正确定位日志、API、链路一次聚合
分析慢查询日志26 分钟10 分钟得到候选原因人工仍需复核业务影响
梳理调用链22 分钟9 分钟链路可解释自动补齐上下游依赖
写入配置变更19 分钟22 分钟需确认安全确认增加必要时长
失败状态不是边角案例，而是 Tool Calling 的产品能力。
当 AI 获得操作能力后，错误不应被隐藏成一句“调用失败”，而要给开发者清楚的下一步和可恢复状态。
阻断调用并提示补充
未提供服务名或时间范围时，系统不发起日志查询，直接说明缺少字段与用途。
规则：必填参数校验显示边界，而非假装执行
无生产权限时，展示当前角色能做什么、需要谁授权以及影响范围。
规则：权限范围可见保留上下文，允许重试
日志服务超时后保存原始任务、参数与错误信息，支持重试或转人工。
规则：失败可恢复预览、确认、回执与回退
配置修改和生产操作必须显示回退方案，人工确认后才执行。
规则：写入必经门禁从 Badcase 回到规则：“直接给出修复动作”被改成“先产出预览，再确认授权与回退方案”。产品不替开发者跳过风险判断，而是把判断所需的信息准备好。
我学到的是：Tool Calling 的价值，不是让 AI 替人操作，而是让操作过程可解释、可确认、可回退。
开发者场景里，信息检索、分析判断和写入操作的风险完全不同。好的 Agent 不只会选择工具，还要知道何时停止、把什么上下文交给人，以及如何记录每一次决策。