面试时怎么问出团队用的是bash式还是类型化工具路线？

消息提到，一篇论文比较了五种工具接口，从类型化工具目录、仅用bash，到让Agent针对固定目录写代码的程序化工具调用。作者的建议是：执行可沙箱化时用bash，合规要求固定工具列表时用程序化工具调用。这个区分，正好可以变成你面试时的提问框架。

不要只问“你们用Agent吗”。可以问：团队的工具接口是固定目录，还是允许Agent写脚本？如果允许写脚本，执行环境怎么隔离？如果必须固定工具列表，是合规要求，还是为了可审计？这三个问题分别指向选型依据、执行环境和约束来源。

听回答时注意两类信号。一类团队强调沙箱、权限边界和脚本编排，工具列表相对开放；另一类团队强调审计、固定接口和可复现，工具目录更收敛。两者没有天然高下，关键是约束从哪来。如果对方只说“我们也在探索”，可以追问最近一次工具接口调整是因为什么。

我的工具调用经验该怎么表述才匹配不同路线？

论文比较的三类方式，对应两种可准备的表述方向。

偏灵活脚本编排的方向，可以讲你如何把任务拆成可执行步骤、如何控制命令边界、如何处理失败重试。重点不是“我会写脚本”，而是你清楚脚本在什么环境下跑、出错时怎么收敛。

偏固定接口调用的方向，可以讲你如何设计工具入参出参、如何做参数校验、如何让调用可追踪。重点不是“我接过很多工具”，而是你理解接口收敛带来的可审计性。

假设一个模拟场景：同一份数据清洗任务，一种做法是让Agent写一段脚本直接跑，另一种是调用三个固定工具分步完成。前者更依赖执行环境隔离，后者更依赖接口定义清晰。面试时你可以主动说出这两种做法的取舍，再问团队目前偏向哪边。这体现的是判断方法，不是实际工作经历。

看到这类研究，求职者该不该押注某个技术方向？

消息还提到，在bash之上叠加类型化工具或Agent自写工具，没有带来可测量的增益。这个结论容易被读成“类型化工具没用了”，但论文的具体实验设置、任务类型和可复现性并不在素材范围内，它是否适用于其他模型或企业场景也不清楚。

更稳妥的做法，是把它当作面试提问素材，而不是择业依据。相关企业是否因此调整招聘要求或岗位设置，素材没有说，也不该替它们下结论。你可以在面试中问：团队有没有做过工具接口的对比测试？测试任务和线上任务差多远？这类问题比押注某个方向更能帮你判断团队。

一个实际可做的小建议：面试前写下三个问题——工具接口是固定还是开放、执行环境怎么隔离、约束来自合规还是工程偏好。面试后按回答归类，再决定下一轮重点展示哪类经验。