给Agent一个搜索接口和一个Python工具，能力为什么不同？
同一笔采购，两种行动方式
我们要计算三项采购总价：红笔3盒、每盒12元；蓝笔2盒、每盒8元；文件夹4个、每个5元。先分别算出36、16、20，再相加得到72元。这个例子不是为了比较谁会乘法，而是看程序允许模型怎样组织工作。
如果只给 lookup_price(item)，模型可以依次查三项价格，再自己组合结果。接口很窄：请求主要包含商品名称，返回主要包含价格与库存。若给 execute_python(code)，模型可以写一个循环，在一次代码执行中组织多次读取、过滤结果并求和。它获得的不只是另一个函数名，而是表达控制流程的能力。
代码工具也不会自动拥有库存数据。若执行环境没有库存文件、库或网络访问能力，一段漂亮的Python仍然查不到价格。表达力指能描述什么程序，访问范围指程序实际能触及什么资源。二者一起决定能力，不能把它们混成“给Python就什么都能做”。
为什么代码能把许多动作装进一个动作
专用工具把选择空间限制在预先定义的参数中。代码工具允许变量保存中间结果，循环重复操作，条件分支处理不同情况，函数复用已有逻辑。这些组合在一次调用里完成，避免每一步都等待模型重新生成请求，但也把更多执行细节交给了代码。
看一次明确的数据流：程序读取三条价格记录，检查三条都包含价格和币种，把数量与对应单价相乘，再累加。这里保存的是三个小计，不是混合后的一个模糊文本。如果蓝笔价格缺失，不能把缺失值默认为0，因为那会把未知变成“免费”，总价从72错误变成56。
我们还要指定代码输出的边界：是仅返回计算结果，还是允许修改库存？同一门语言可以做两件事，但本课任务只授权查询。为了算价而给写库存、发网络请求或启动任意进程的能力，并不是表达力的必然要求，是执行环境配置的选择。
在相同数据上比较，不要偷换任务
三个小计怎样成为72元
先预测结果，再逐步展开；最后只改变一个条件，找出最早发生分歧的位置。
教学构造场景 · 按下方规则逐步回放；不调用真实模型，不代表实际成功率。
需求数量3、2、4；单价12、8、5。
- 1. 逐项相乘
红笔3×12=36；蓝笔2×8=16；文件夹4×5=20。
- 2. 检查单位
所有小计均为人民币元，可以相加。
- 3. 聚合
36+16+20=72。
红笔3×12=36；蓝笔2×8=16；文件夹4×5=20。
先预测，再核对结果与原因
总价72元。专用工具与代码工具应在同一数据上得到同一算术结果。
省调用不等于一定更可靠
如果三次查询彼此独立，程序可以并行运行，再统一返回数据；这不一定要由模型生成任意代码，一个专门的批量查询工具也可以做到。反过来，代码里写了三次串行网络请求，也不会因为它们处于一个代码块就自动变快。真正节省了哪些等待，需要看实际执行结构。
再改一个条件：红笔价格用元，文件夹价格用美元。三个小计虽然都是数字，直接相加仍然错误。类型检查只能说明它们可被计算，语义检查还要看币种、单位、时间与商品对应关系。代码让计算更一致，不会自动让输入事实更正确。
第三个条件是数据量。只查三项时，模型逐次调用的开销可能能接受；查一千项时，循环和批处理更有价值。不过批量动作的失败范围也更大，应保存哪些项成功、哪些失败，考虑限流与重试。把一千次操作塞进一个长脚本而不留中间状态，出错后可能更难定位。
选择工具时可以问三个具体问题：任务需要哪些组合能力；这些能力能否用更窄的接口表达；执行端如何限制副作用并验证输出。答案可能是只读批量查询，而不是“越通用越先进”。评价时比较相同任务、相同数据访问权限与同样的成功判据，否则所谓提升可能来自额外权限而非更好的规划。
自己解释一次
代码工具一次返回72元，如何确认不是编出来的？
检查读取了哪三条记录、对应数量、单位以及36、16、20三个小计。执行返回能提供证据链，但仍需核对数据来源和算法；不能只看输出数字。
批量查询一定要暴露任意Python吗？
不一定。一个接受商品列表、返回逐项状态的只读批量工具也能实现并行或聚合，并且更容易限制参数与副作用。
少一次模型调用就一定更快吗？
不是。工具内部可能做更慢的串行工作，也可能发生启动和传输开销。应分别统计模型生成、工具等待和整体完成时间，才知道省在哪里。
下一课接上真实服务边界：无论选择窄函数还是代码，工具怎样被发现、连接和调用，以及MCP到底统一了哪一层。