问题和思考：谁是最好的Agent Tools的生产者

问题和思考谁是最好的Agent Tools的生产者最近在不断的给Agent开发大量的Tools在这个过程中出现很多问题并思考了很多内容存量系统的Agent Tools构建在Agent大规模落地之前各类存量系统已在组织工作和管理中占据主导地位。这些存量系统承载着核心业务流程以Agent Tool的形式安全、高效地对其进行开放是当前Agent工程化过程中一个极具挑战且值得深入思考的问题。它不仅涉及技术对接更涉及人机协作的转变从工程师面向系统转向Agent面向业务与用户这本质上是接口设计思维从工程师接口向Agent接口的转变。尝试一开发工程师主导将对应系统的开发工程师指定为MCP Server的Owner这符合直觉他们最懂系统实现。他们对系统边界最熟悉但未必熟悉Agent的决策模式和MCP Server组合方式。但实践中暴露了设计思路错位的问题工程师习惯性地将MCP Server当作传统的系统对接或API服务来实现解决问题的思路还是RPC风格或者REST风格的接口设计方式。交付颗粒度与业务流程脱节。开发排期按技术模块或系统功能进行而非端到端的业务流程。一个迭代周期内交付的Tools往往只能覆盖业务流程的碎片无法形成闭环。这在将任务交给Junior工程师时尤为突出——经验不足导致他们难以抽象出业务主路径。Tools参数设计面向工程师而非Agent。参数数量过多、语义过底层需要传入各种系统内部ID、主键、配置项等。例如内部需求管理系统MCP Server第一批交付了大量查询类MCP Tools但业务方根本无法直接使用。还有因为要查询某个需求必须先调用另一个MCP Tool获取项目ID而项目ID对业务人员来说是“透明”的。这导致Agent调用链过长、错误率高用户体验极差。尝试二产品经理VibeCoding受Vibe Coding等趋势影响我们尝试让产品经理主导MCP Server设计。他们对业务流程理解深刻能快速梳理出MVP流程并定义Tool列表这一点优势明显。但也出现了新问题Tool设计粒度失衡产品经理倾向于设计大而全的复合MCP Tool把复杂流程一次性打包中间的异常处理、分支逻辑、权限校验等大量逻辑校验缺失或者考虑不全面。 结果是MCP Tool 在运行时表现出较强的黑盒特征用户难以理解 Agent 的决策依据与执行路径从而产生行为不可预测的感受。Tool集合边界模糊随着时间推移MCP Tools之间职责重叠、边界不清。大模型在MCP Tool 选择阶段频繁出错调用错误MCP Tool或重复调用。缺失场景覆盖产品经理虽然懂业务主流程但对边缘场景、异常路径、跨系统交互的细节掌握不足导致很多业务方真正需要的原子级或辅助性Tool长期缺失。尝试三测试开发工程师测试开发工程师原本寄希望于能够产品经理的一些业务视角的能力也兼具了部分开发工程师视角的技能还加持了软件测试思维原本期望他们能交付出既懂业务边界又具备技术鲁棒性的MCP Tools但是这个独立的角色同样出现了一些发人深省的问题**深陷全链路自动化思维导致 Tool 的功能边界向业务流水线倾斜。**融合后的角色天然擅长设计端到端的自动化测试链路。在主导MCP Tool设计时他们极易把原本应该原子化的接口做成一个形似测试流水线的超大复合MCP Tool。例如他们不会单独提供优惠验证和库存验证的MCP Tool而是会交付一个执行下单全链路测试的MCP Tool。这种设计剥夺了大模型在中间步骤进行动态决策和组合的灵活性让 Agent 退化成了执行固定脚本的自动化批处理工具。陷入数据工厂与防御性校验的夹击。作为测试他们本能地在 Tool 内部塞满极其严苛的前置条件校验作为开发他们又习惯于提供各种操纵底层数据的快捷方式如绕过前端校验直接修改数据库状态。这导致最终交付的MCP Tool 集合呈现出极端的两极分化一类是门槛极高、Agent 稍微输入不合规就会报错拦截的防御型MCP Tool另一类是暴露了过多底层逻辑的特权数据MCP Tool。大模型面对这种缺乏业务语义抽象、且技术细节暴露过多的 Tool 集合调用错误率会显著上升。**以非黑即白的断言代替语义化反思扼杀了 Agent 的容错与纠偏能力。**长期从事自动化测试工作的工程师更习惯于使用明确断言来判断执行结果。他们设计的MCP Tool在执行完毕后返回给大模型的数据往往是高度结构化、冷冰冰且缺乏上下文的测试断言报告例如{“result”: false, “error_code”: “ERR_409”}。这种返回对机器程序很友好但对大模型来说极不可读。大模型真正需要的是包含丰富业务上下文、带有建设性提示的语义化文本返回例如由于当前商品库存仅剩1件无法满足您购买2件的需求建议询问用户是否调整数量。缺乏语义弹性的断言式返回导致 Agent 无法基于报错进行智能的自我修正与逻辑规划。角色反思三次尝试暴露出的核心问题并非来自某个角色能力不足而是来自单一角色视角的天然局限。Agent Tools的设计既涉及业务语义建模又需要理解 Agent 的决策模式既要完成系统能力抽象又必须兼顾工程实现约束。这些能力天然分散在不同职能之中因此 Agent Tools很难由任何单一角色独立设计完成而更适合作为一种跨职能协同设计的产物。个人观点放到长远来看业务语义建模、工程实现约束、理解Agent的决策模式和系统能力抽象这些都是现有团队角色的一部分能力这些能力会伴随着团队的发展逐渐的汇聚到某一些人身上慢慢的进行综合能力的转变从而实现一种新的角色这个角色拥有团队需要的统一技术栈能力能够在AI的辅助下地理交付能够站在用户角度抽象出业务模型掌握系统能力抽象更方便的规划和设计“不大不小”的Tools这个角色叫什么工程师其实并不重要了但是这角色和以往团队中角色能力都有交集又都有差异。新Tools的构建新 Agent Tools 的构建就没有存量系统那样沉重的负担了。它从零开始没有历史包袱和遗留接口的约束。既然单一角色无法独立定义完美的Tool我们在新系统的构建中彻底摒弃了单兵作战的交付模式走向了智能体原生的跨职能协同。尝试四跨职能联合设计工作坊当前最优解我们把产品经理、开发、测试以及一线业务专家、大模型工程师拉到同一个工作坊中形成了一个短周期的工作坊第一步业务语义建模产品经理 业务专家主导 剥离底层技术细节定义 Tool 的业务契约、核心用户意图和预期输出语义。第二步决策兼容性审查大模型工程师 / 架构师 评估 Tool 粒度是否适配 LLM 的规划-选择-执行ReAct循环重点检查参数高层化程度和描述的大模型可读性。第三步鲁棒性加固开发 测试 完成底层实现同时将冷冰冰的测试断言重构为富含上下文的语义化反思返回。Tool 设计的黄金原则核心规范在这一套机制下我们沉淀出了新 Tools 设计的五条原则有限工具与黄金粒度原则控制 Tool 的总数拒绝无节制的接口膨胀。 Agent 在面临成百上千个 Tool 时召回和选择的准确率会直线下降。我们必须按照场景对工具进行深度封装。- _反例_ 同时提供 list_users、list_events 和 create_event 三个底层原子工具让 Agent 自己去拼装。 - _正例_ 将它们融合成一个高内聚的场景工具schedule_event排程事件由后端去处理多表查询和前置依赖。理想状态是一个 Tool 对应一个“用户可理解的独立业务动作”。自解释的描述与多维语义命名原则Tool 的命名和描述本质上就是对大模型的 Prompt Engineering。 尽量避免任何模糊不清的说明。在命名上我们采用两套清晰的语义维度- 按服务导向 如 jira_search清晰定义业务边界。 - 按资源导向 如 jira_projects_search、jira_users_search明确操作的对象实体。 同时必须在代码中提供极其详尽的自然语言描述description和示例examples消除大模型的理解歧义。上下文富化原则返回高语义密度的有用的上下文拒绝返回对人类或大模型而言透明的内部主键。- _不推荐的硬编码返回_{id: 1001}大模型拿到后一头雾水无法在接下来的对话中利用该信息。 - _推荐的富上下文返回_{name: criss, age: 40}。 输入输出必须是具备业务表现力的社会语言让 Agent 能够“看懂”发生了什么从而顺畅地承接上下文。具备自愈能力的“可理解错误”Error as Prompt原则Tool 的错误信息不是为了记录日志而是为了引导 Agent 决策如何修复。 必须返回有用的、具备建设性提示的 Error Message扼杀非黑即白的冷冰冰断言。- _反例_ 返回 {result: false, error_code: ERR_409}。Agent 无法基于此进行智能自我修正。 - _正例_ 返回 “由于当前商品库存仅剩1件无法满足您购买2件的需求建议询问用户是否调整数量”。Agent 读取到这种可理解的错误后能立刻规划出下一步的纠偏逻辑。渐进式演化原则先交付 MVP Tool 集快速上线观察 Agent 的实际使用日志LLM Traces再针对高频选择错误和边缘缺失场景进行高频的迭代补充。终局思考谁是最好的 Agent Tools 生产者回到最初的疑问谁是最好的生产者短期来看是跨职能工作坊 强有力的平台守门人技术架构师。 它用机制抹平了单一角色的局限确保交付的 Tools 严格闭环在上述五条原则之内。中期来看是组织自然孕育出的复合角色。 正如前文所言他叫什么工程师并不重要他甚至可能在 AI 的辅助下实现独立交付。他一手握着底层的技术约束一手牵着上层的业务语义同时对大模型的心智模型了如指掌。而长期来看最好的生产者或许是 Agent 自己。 未来的演进方向极有可能是人类工程师只需按照传统最舒适的方式维护好底层的原始 API随后由一套Agent2API 编译器读取全量文档与日志自动针对不同的业务场景动态编译并裁剪出最符合上述规范的 Tool 集合。终态就是大模型接手了一切只要需要它就会自主构建后提供给我们无论是一个UI还是一个API都有大模型自己决定用完即还释放一切的资源留下数据和所有审计可查痕迹。Agent Tools 的生产本质上是将人类组织的API翻译成通用智能可以理解的。在这门全新的翻译艺术中成功的关键不是技术卷到了什么高度而是看设计者能否打破固有的角色边界真正给 Agent 赋予一份业务同理心。