CLI Agent 开发短记：上下文与工具如何分工

CLI Agent 开发短记：上下文与工具如何分工

我第一次做 CLI Agent 时，把整段日志和源码都塞进提示词。它偶尔答对，偶尔却围着无关 warning 打转。后来我才明白，模型不负责替我判断什么重要；上下文越长，也可能越难找到关键线索。

现在我只把任务目标、已确认事实和约束放进上下文。文件内容、diff 和完整日志交给只读工具按需取回。AI 的输入是经过截取和脱敏的片段，输出是下一步建议；是否执行命令、是否修改代码，仍由程序的权限校验和人工确认决定。

fn excerpt(lines: &[String], limit: usize) -> String {
    lines.iter().take(limit).cloned().collect::<Vec<_>>().join("\n")
}

这只能控制返回长度，token 数量应使用对应模型的 tokenizer 计算，不能用字节数估算当成准则。路径、命令参数和用户文本也不能直接拼进 shell。

我会最后回到原始文件核对 Agent 引用的位置。涉及删除、网络访问或提交改动时，Agent 只能提出建议。这样做没那么炫，但出现问题时至少知道该从哪一层查起。

补充记录（第 1 篇）：我会把这条建议落实为一个可复现的小检查，而不是停在概念层面。先写清输入、预期行为和失败时的处理方式，再在干净环境中运行最小示例；结果与假设不一致时，回到文档和代码定位原因。这样既能保留学习过程，也不会把局部经验包装成通用结论。

第 1 篇的收尾检查是：删掉无关输入，保留一个能失败的反例，并写下我准备如何确认修复是否真的生效。若没有可执行的检查，就把结论标为待验证，而不急着把它变成规则。

第 1 篇的延伸练习：把文中的判断拆成一张小表。第一列写触发条件，例如输入超过限制、依赖返回异常或调用者取消；第二列写程序可观察到的信号，例如错误类型、队列状态或测试断言；第三列写允许的处理动作，以及谁有权执行它。随后只实现其中一条最小路径，并故意制造失败输入检查结果。若失败路径没有明确输出，就不要继续增加功能。这样做虽然比让工具直接补全整段代码慢，但能迫使我先理解所有权、资源释放和调用方预期。完成后再删去不必要的分支，补上一个回归测试，并把运行命令与限制条件记在提交说明里。读者若要采用相同思路，应替换为自己的编译器版本、依赖版本和业务目标；示例不能替代项目验证。

第 1 篇还应补一个边界案例：当输入为空、依赖不可用或用户中途取消时，程序是否仍能给出可理解的结果。把这些案例写成小测试后，再检查日志是否泄露路径、账号或原始内容。只有正常路径和失败路径都能说明白，才把这段做法放进自己的工作流。

第 1 篇的发布前检查：确认标题没有承诺超出正文的范围，示例代码能独立阅读，参数没有被写成通用答案；再让一位不了解上下文的人按步骤复述风险点。如果对方无法判断何时该停止或回退，就继续删减结论、补充限制，而不是增加口号。