Agent 里上下文负责解释工具负责给出证据上下文用于保存任务目标、用户代码、必要约束和已验证的中间结论工具用于编译、测试、检索等确定性操作。两者混在一起时常见后果是 Prompt 膨胀、模型把工具输出误当指令或把未经验证的推断写回状态。工具接口应有明确输入、超时、资源限制和结构化结果。模型只根据结果决定下一步不能自己拼接 shell 命令或绕过验证器。type TestResult struct { Passed bool json:passed Stage string json:stage Detail string json:detail }失败日志只返回足够诊断的信息避免把完整用户代码、环境变量或内部路径塞回 Prompt。工具失败后是否重试取决于错误类型编译错误通常需要改变代码超时可能需要限次重试或降级。验证时用同一任务比较“只靠 Prompt”与“带工具结果”的输出并检查工具调用次数、失败分类和取消是否能传递到子进程。状态里只放可复用的事实上下文不是聊天记录的无限副本。可以保留题目约束、已确认的语言版本、测试阶段和上一轮工具的摘要大段编译日志、完整源码和重复检索内容应放在受控存储中用引用或截断摘要连接。这样既减少 token 消耗也能避免工具输出里的文本意外改变模型的执行方向。工具结果最好区分“执行是否成功”和“业务判断是否通过”。一次测试命令正常退出但测试用例失败仍然是一次成功的工具调用如果把两者混为一个error上层就无法决定该让模型修代码还是提示基础设施异常。Stage也应来自固定枚举而不是让工具随意返回自然语言。不把工具输出当作可信指令检索到的网页、用户提交的代码注释和测试输出都可能包含类似指令的文本。它们应被标记为数据并在提示词中明确模型只能把这些内容作为证据不能据此改变权限、跳过验证或执行额外命令。命令参数由服务端根据结构化字段生成不能直接采用模型返回的一段 shell 文本。验证可以准备三类用例正常通过、工具返回可诊断失败、工具输出中夹带无关指令。检查模型是否只引用允许的字段失败时是否停止后续危险操作以及日志和 Prompt 中是否没有泄露敏感内容。3. 证据要有来源和失效时间工具给出的结果并不会永久有效。编译通过只说明当前代码和依赖组合能通过检索命中也只对应某个索引版本。把结果写入状态时最好同时保存来源、执行时间和适用范围。下一步需要复用时先判断它是否仍适用于当前分支、当前权限和当前输入而不是把旧结论当作事实。有些证据应当只能读一次例如包含临时签名或内部路径的诊断输出。摘要里保留错误类别和关联标识即可详情放在受权限控制的存储中。模型需要更多信息时走显式查询不要把整份原始结果反复拼进上下文这既浪费 token也扩大了错误指令被放大的机会。4. 工具契约要包含失败格式不少工具只描述成功返回值失败时直接吐出一段自由文本上层只好猜该不该重试。更稳妥的契约会区分参数错误、权限不足、可重试故障和不可恢复故障并给每类一个稳定代码。模型看到的是受限字段服务端仍保留完整诊断。有了这个边界重试策略也能由程序决定而不是交给模型揣测。比如参数错误应退回补充信息权限错误应停止并提示授权短暂网络故障才进入有限重试。错误分类越早做后面的流程越简单。
