Agent 的能力边界
Agent 不是银弹。它的价值在于处理路径不确定的任务——需求模糊、步骤需要动态决定、结果需要判断质量。当路径确定时，确定性工具远胜 Agent。
以一个常见反例说明：把"把 Markdown 转成 HTML 并部署"这种步骤固定、输入确定的流水线交给 Agent，等于用大模型当脚本跑。每多一次模型调用，就多一份延迟、成本和失败面。直接写一个 30 行的构建脚本，快几个数量级，且可复现。我见过一个 dispatch 流程本来一段 sed 能解决，被包成 Agent 循环后偶尔幻觉出错误参数，调试成本远超省下的那点"灵活"。
反过来，当任务需要"读一份陌生代码库、判断哪段逻辑该改、再决定改法"时，确定性工具就力不从心——这里 Agent 的反思与工具调用循环才真正发挥价值，因为它能在不确定中边走边修正。
判断边界的一条经验：如果你能在写代码前把步骤枚举清楚，就别用 Agent；如果连你自己都要边读边决定，那 Agent 才有理由存在。把 Agent 当成"会判断的同事"而非"更聪明的脚本"，能力边界的取舍就清晰了。
← 返回想法列表