问题和思考：谁是最好的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 赋予一份业务同理心。
