题解生成中，上下文和工具如何分工

题解生成中上下文和工具如何分工题解系统常把题面、历史题解、运行日志和整棵 AST 一起塞进模型上下文。这样既增加成本也会让模型更难判断哪些信息可靠。更合理的做法是模型负责解释和组织语言程序负责可重复计算与验证。划清职责LLM 可以提取题目的约束、解释候选思路、把验证结果整理成读者能理解的文字。编译、执行样例、解析 AST、检查复杂度声明和比较输出应由受限工具完成。复杂度分析尤其需要谨慎。静态分析只能在特定语言子集和规则下给出近似结论对递归、数据相关分支或外部调用工具应返回“无法确认”而不是伪造精确复杂度。符号工具同样需要由输入模型决定是否适用不能把所有递推式直接交给求解器。工具协议要包含失败状态type ToolResponse struct { OK bool json:ok Data json.RawMessage json:data,omitempty ErrorCode string json:error_code,omitempty } func ValidateToolResponse(resp ToolResponse) error { if resp.OK len(resp.Data) 0 { return errors.New(tool returned no data) } if !resp.OK resp.ErrorCode { return errors.New(tool failure has no error code) } return nil }工具输入应有大小限制、超时和权限边界。工具结果进入模型前要标明来源和可信度避免把用户提交的代码、错误日志或检索内容当成指令执行。最小验证集为每类工具准备正常、超时、格式错误和“不支持”的用例。发布前抽查最终题解解释是否与工具结果一致工具失败时是否明确说明未验证是否把猜测写成了事实。这样比追求单一“准确率”更能发现问题。