#MCP

rss · ByteByteGo · 10月28日 15:31 「背景」 企业内的大模型要回答系统内部问题，必须借助可调用工具；但 Uber 各团队各自接入 MCP，造成工具发现分散、权限与运维重复，且后端混用 HTTP、gRPC 和 TChannel。 「方案」 文章梳理的 MCP Gateway 以控制面/数据面分离为核心：MCP Registry 保存服务器与工具目录、启停配置和变更记录，Proxy Gateway 处理实际请求并返回 MCP 兼容结果。AutoCrawler 从现有 IDL 提取方法、请求响应结构和工具 schema，并用 LLM 改进描述；对原生 MCP 服务器则靠心跳和 listTools 注册。新发现的工具默认禁用，需属主审核、批准差异后才能启用，并可回滚。运行时网关周期性刷新内存映射，生成虚拟 MCP 服务器，把调用转成 gRPC/Protobuf、HTTP 或 TChannel 请求；权限可按服务器或单个工具配置，还支持 PII 脱敏和第三方 token 交换。面对海量工具，Omni MCP 提供渐进发现，Response Projection 裁剪返回字段，Code Mode 让编码代理用 shell 和文件处理结果。文章也留下疑问：禁用能否绕过刷新间隔立即生效，以及渐进发现和字段选择带来的额外往返与决策成本。 「启示」 作者的核心结论是，让代理接入企业能力的最快路径是复用现有 API，而不是重写服务；生产级代理系统最难的部分也不是模型本身，而是发现、安全与可靠性这类连接组织。 标签: MCP, AI agents, API gateway, tool discovery, platform architecture

rss · ByteByteGo · 10月26日 15:30 「背景」 Salesforce 首版 Agentforce 把规则、数据查询和工具说明全放进一个提示词，规则一多模型就漏指令；在医疗、招聘等场景，这不可接受。 「方案」 新架构把四项职责移出提示词：Agent Script 用代码写确定性规则，经 Agent Graph 由 Atlas 引擎执行，只在推理时调用模型；Data 360 跨源取数、对齐字段并解析身份，生成统一画像；Agent Context Engine 负责解析、规划、排序、治理和编译上下文，只送入当前问题所需数据；Agent Identity 给智能体独立身份，执行前同时校验用户与智能体权限。对外，AIforce 与 Headless Toolkit 通过 API、skills 和 MCP 接入 Slack、Claude，MCP Server 以 discover、describe、dispatch 等四个工具按需检索工具定义，避免数百个工具占满上下文。Salesforce 称首版约 8 条指令后模型开始丢规则，IFScale 中最强模型在 500 条指令下也只遵循 68%；其演示称上下文引擎把同一问题的输入从 12.4 万 token 降至 9 千。作者提醒代码只适合可预测部分，并追问 ACE 治理时用的是用户与智能体权限的交集，还是只看用户权限？若是后者，智能体仍可能把无权调用的数据编进回答。 「启示」 作者的核心结论是：智能体可靠性来自代码、数据、上下文和身份系统的分层约束，而非更长的提示词；但 Salesforce 的效果多为厂商叙述，权限一致性等细节仍待验证。 标签: AI agents, agent reliability, context engineering, Salesforce Agentforce, MCP