不过实话讲，子Agent之间怎么传上下文、传多少，平台给的是默认策略，复杂场景还得自己调，不是配好就万事大吉。一句话先讲清这套架构：复杂任务别指望一个Agent硬扛，让一个"主Agent"当指挥，把活拆给几个"子Agent"分头干，再汇总。一次调研要多次模型调用，主Agent拆一轮、N个子Agent各跑一轮、主Agent再汇总一轮，整体响应是分钟级的，急性子用户等不及。"市场规模子Agent"就专

结论:在 RN 出海 App 里接一个拖配台搭的智能体,坑最深的是 i18n——不是界面文案,是智能体本身的回答语言。我返工两次才理顺,把方案留这。

—查内部订单、读业务系统、触发某个工单。平台自带的插件和 MCP 再多，也覆盖不到你公司私有的那套系统。这时候就得自己把内部接口"封装成 Agent 能调用的工具"。这篇记录下我封装内部 API 的过程和几个坑，给同样要打通私有系统的后端同学参考。

中文问题 → 翻成英文query → 检索英文知识库→ 命中英文段落 → 模型用中文+英文原文出答案末尾我特意保留：答案给中文结论，但把依据的英文原文片段也附上。因为是技术资料，工程师反而想看英文原文核对术语，纯中文他们不放心。

先把最重要的一条放最前面：内部用的智能体，，你不主动加鉴权和数据隔离，它就是个把全公司敏感信息平铺给所有人的窗口。我们差点出事，复盘出几条避坑经验，写给同样在搭内部 AI 助手的人。

公司里的答疑机器人一多就乱：HR 一个、IT 一个、报销一个，新员工根本记不住该去哪个群问哪个。上个月我把三个入口合成了一个——前面加一层"意图识别"，识别完再把问题转给对应的子智能体处理。用的是一个零代码搭智能体的，整条链路没写后端代码，记一下搭法和坑。

台上搭的时候攒的——零代码省了底层功夫，但这些"怎么把 Agent 调好"的手艺，是平台教不了、得自己踩的。没什么宏大道理，都是些细碎的、踩出来的小经验。越具体越稳，把身份、能做什么、不做什么、拿不准怎么办全写清。想要什么样的输出，直接给一两个示范，胜过一堆形容词。尤其改知识库、改 Prompt 后，验证生效再走。Agent 链路慢，别拿普通接口标准卡它。模型对开头更敏感，重要的别埋在末尾。别全程

台上搭的时候攒的——零代码省了底层功夫，但这些"怎么把 Agent 调好"的手艺，是平台教不了、得自己踩的。没什么宏大道理，都是些细碎的、踩出来的小经验。越具体越稳，把身份、能做什么、不做什么、拿不准怎么办全写清。想要什么样的输出，直接给一两个示范，胜过一堆形容词。尤其改知识库、改 Prompt 后，验证生效再走。Agent 链路慢，别拿普通接口标准卡它。模型对开头更敏感，重要的别埋在末尾。别全程

大模型按量付费，最怕的是"用着用着不知道花了多少"，月底账单一出来心头一紧。尤其多个 Agent、多个调用方时，钱花在哪、谁花得多，一笔糊涂账。给 Agent 做用量统计和配额，是把成本攥在自己手里的前提。记一下我做的几件事。

做企业文档问答的都知道，模型本身不是瓶颈，召回才是。我给公司一堆产品手册搭了个问答助手，第一版答得稀烂——明明文档里写了的东西，它说"未找到相关内容"。排查下来，问题全在召回环节。记一下我调的三个地方。