对API的运用方式已经更新，现在需要让接口能够被具备推理能力的系统掌握，模型上下文协议为系统代理提供了执行实际工作的手段，这促使我们调整编程思路，面临新的难题。

观念转变

从前，我们以为API只是程序员之间的约定。但现在不一样了，随着时代进步和技术革新，接口需要变成能被智能模型识别的方案。老办法已经无法满足现在的要求，在开发代理软件时，必须换个角度去考虑，不能再沿用旧模式去编写工具和MCP服务器了。

工具调用设计

在为代理制定方案时，对于每一个提示和回应的组合，可以决定让代理使用哪些工具，借此判断代理是否了解这些工具的用法。要求代理在调用工具和生成回应之前，先展示相关思考过程，这种做法或许会促使代理进行更连贯的推理，有助于提升大型语言模型的表现，同时也能分析代理为何选择使用或放弃某个工具。

性能提升探索

真实检验显示，即便是“专家”制作的方案执行，也依然能取得更优表现。例如方案能借助更详尽的资料来优化反馈，或者通过单次调用就完成一系列流程。方案需要让助手像人一样分解并处理事务，以此降低信息传递的成本，这对方案的制作标准设定了更严格的条件。

工具命名与选择

根据服务与资源对工具进行命名空间分类很有必要，这有助于代理在恰当时候选用合适的工具。选择性地实现能体现任务本然划分的工具，可以降低加载到代理环境中的工具及说明的总量，同时还能把代理的计算工作迁移到工具的调用环节。

交互灵活性设计

代理需要经常和自然语言以及技术代码灵活配合，哪怕只是为了启动下一个工具。可以通过在工具里设置可选的参数，让代理选择回答是简单还是全面。工具的回应方式也会改变评估的效果，没有一种方法适合所有情况。

工具注解重要性

制作MCP服务器的辅助程序时，程序上的标记可以表明哪些辅助程序需要连接公共区域，或者会引发破坏性影响。要开发可靠的代理程序，软件工程方法需要从可预见的常规方式转变为不可预见的随机方式。

你认为软件开发流程转变为不确定性方法，会遇到哪些实际困难呢？请在留言区表达你的见解，同时记得给这篇文章点赞和转发。