面经 | Business Agent / AI | 🔥🔥 | Meta
2026(9月底–10月初) Business Support Engineer - Meta Business Agent @ Meta | Austin, TX · Virtual · 3 轮 | 😐 Neutral | Medium-Hard
Meta Business Agent 组，电面加两轮 virtual onsite。
Round 1 — Phone Coding
Tool Call Parser。模型返回一个对象，带 name，arguments 还是字符串。解析成结构化的 call；arguments 不是合法 JSON 就返回失败，不要直接抛；空串当成 {}。
外层先拿 dict，再对 arguments 做 json.loads。空串第一次就处理了。挂在双重编码：arguments 解析完还是字符串，里面才是 JSON 对象，他们的用例要 dict。hint 之后发现还是 string 就再 parse 一次。
follow-up：arguments 字符串截断在某个 key 中间，希望把已经完整的字段捞回来。只口头画了括号/引号扫描，恢复那段没写。
Round 2 — Coding
一次 agent run，步骤是 (tool, args_hash, obs_hash) 列表。找最早进入循环的下标：某一段连续 fingerprint 在更早已经原样出现过。没有循环返回 -1。
每步当三元组，扫重复后缀。第一版只抓住了长度 1（同一个工具连打）。他们给了 lookup_order 和 send_reply 交替、hash 不变的例子。改成枚举 period 长度到 n/2，用例过了。
follow-up：args_hash 因为模型换了说法而变了，业务状态其实没动，希望有超出原始 args 的 state fingerprint。只说了“把工具返回的订单状态拿去 hash”，状态对象怎么拼没定义完，时间到了。
Round 3 — System Design
给 Meta Business Agent 前面加一层 tool execution gateway。模型提出 tool call，gateway 决定能不能跑、打到 partner API 或内部服务，并留下 support 能查的记录。
就画了 catalog + authz + execute + audit。catalog 存 schema 和有没有副作用。authz 每次用业务身份再鉴权，不用大 service account。有副作用的工具（send_reply、create_order）用 run id + step id 生成 idempotency key，避免重试双发。
追问超时：按工具设 deadline，partner 慢的时候 agent 看到什么。我说返回可分支的 timeout 错误，有副作用的不自动重试。最后问两个 region 都以为第一次失败了怎么办。提到 idempotency key 存储，key 留多久、partner 收下请求却没返回 id 怎么对账，没展开完。