Plaid AI Tooling 面试经验

这是一次 Plaid Senior Software Engineer — AI Tooling 的三轮面试。重点不在模型内部，而在 Agent 如何真正进入 production：权限、工具安全、失败恢复、幂等性，以及一个内部 workflow 到底有没有帮用户节省时间。

面经 | AI / SWE | 🔥🔥🔥 | Plaid

2026（7–9 月）· Senior Software Engineer - AI Tooling · 本科 · 全职 · Plaid · LinkedIn 海投 · Virtual Onsite · 🙂 Positive 😐 Average · Pass · 在职跳槽。

这个岗位虽然 title 是 AI Tooling，但实际面下来感觉更像 backend / internal platform + Agent engineering，不会花很多时间问 transformer 或训练模型。他们比较关心的是：一个 Agent 真正给公司内部的人用以后，权限怎么管、tool 怎么安全调用、失败以后怎么办、怎么知道它到底有没有帮用户省时间。很多问题都不是特别难，但是会一直加 production constraint。

Round 1：Technical Deep Dive — Agent / Internal Tooling

第一轮基本是从过去项目开始。让我挑一个自己做得比较深的 AI / Agent 项目讲，我讲的是一个内部 workflow automation 项目。前面没有特别八股，主要一直追我当时为什么这么设计。

其中一个问题是：

你们怎么让模型老老实实调用工具，不瞎编参数？

我回答大概是 tool schema 本身尽量做 strict，参数用 structured output / JSON schema validation，真正执行之前 backend 还会再做一层 validation。因为不能把 LLM 输出当成 trusted input。

如果是比较危险的 action，比如改用户数据、发邮件、退款这种，我不会让模型直接执行，而是先生成一个 action proposal，再经过 permission check，有些情况还需要 human approval。

面试官接着问：

如果参数 schema 都对，但是模型选错工具怎么办？

这里我答的是需要把 tool selection 和 tool execution success 分开评估。比如 offline eval 里面不只是看最终 answer 对不对，还会单独记录：

• tool selection accuracy
• argument validity rate
• execution success rate
• unnecessary tool call rate
• end-to-end task success

然后他又问了一个挺实际的问题：

工具调用失败、超时了怎么办？

我回答不是所有 failure 都应该 retry。像 timeout / 5xx 可以做 exponential backoff，但 validation error 或 permission denied 重试基本没意义。

另外一些有 side effect 的 tool，retry 之前一定要考虑 idempotency。不然 Agent 以为第一次失败了，实际 action 已经执行成功，再 retry 一次就有可能出事故。

这里聊得比较久，感觉他们非常在意 Agent 不是 demo，而是真的要接 production system。

后面还问：

如果这个 Agent 给 Support 用，Support 可以查一些 customer information，但是不能看到所有敏感字段，你权限怎么设计？

我回答不会直接给 Agent 一个很大的 service account。更倾向于 request 带上 user identity / role，tool gateway 每次执行的时候重新做 authorization。Agent 本身只负责决定“想调用什么”，最终“能不能调用”还是 deterministic policy 决定。

这一轮我感觉最核心的不是你会不会 LangChain / LangGraph，而是你有没有真的想过 Agent 拿到 production permission 以后会发生什么。

Round 2：System Design — Internal AI Workflow Platform

第二轮比较贴他们 JD。Plaid 现在很多 Ops / Support team 有自己的 manual workflow。比如一个 support ticket 进来以后，需要查 account 状态、查过去的 transaction、判断可能是什么问题、去不同 internal system 找信息，最后生成回复或者执行某个操作。

现在他们想做一个 internal AI platform，让这些非工程团队自己搭 workflow，让我设计这个系统。

我一开始先把东西拆成：

workflow definition / agent runtime / tool registry / auth / execution state / observability

然后 interviewer 问：

为什么不直接让他们全部在 Retool 或者 Zapier 类似的东西里面做？

这个问题我感觉其实是在考 product judgment，不完全是 system design。

我回答是，不是所有 workflow 都应该做成 Agent。如果流程是 deterministic 的，比如固定查三个 API 再更新一个字段，普通 workflow engine 反而更简单、更稳定。

Agent 比较适合的是中间存在 unstructured input、reasoning 或者动态 tool selection 的部分。所以我会允许一个 workflow 里面同时有 deterministic node 和 agent node，而不是所有东西都扔给 LLM。这个点面试官好像比较满意。

后面开始问 runtime：

如果一个 Agent 跑到一半挂了怎么办？

我回答每一步 tool execution 都要有 persisted state，不能只把整个 Agent execution 留在 memory 里面，大概类似：

workflow_run
step_run
tool_call

每一步都有自己的 status。如果 worker crash，新的 worker 可以从最后一个 completed step 继续，而不是把整个任务从头 replay。

然后他马上追：

如果上一步是“refund customer $100”，执行成功以后 worker 挂了，但是还没来得及把 status 写成 success 怎么办？

这里就变成 distributed system 题了。我答的是 tool 本身需要支持 idempotency key，或者我们在 execution layer 给每一个 side-effect action 一个 stable request id。否则单纯靠 workflow state 没办法解决这种 ambiguous failure。

后面又聊 auth。比如 Ops team 自己创建一个 workflow，里面选了一个可以访问 financial data 的 tool，怎么防止他们越权？

我的回答是 tool registry 不只是存 description / schema，还应该存：

• required permission
• allowed caller
• data classification
• side effect level
• approval policy

runtime 每次真正执行的时候还是要经过 policy layer。不能因为 workflow 创建的时候通过了权限检查，就认为以后永远都能执行。

最后问怎么评估这个 platform 有没有价值。我一开始说 task success rate。他接着问“还有呢？”，我补了：

• workflow completion rate
• human intervention rate
• tool failure rate
• latency
• cost per successful task
• escalation rate
• time saved per ticket

最后其实还是要落到 business metric，比如 support handling time 有没有下降、同样的人能不能处理更多 ticket。

这一轮感觉很 Plaid。架构本身没有要求特别花哨，但是每画一个 component，他们都会问：这个东西为什么存在？谁能调用？失败怎么办？

Round 3：Coding — Workflow Executor

最后一轮是 coding，不是 LC 原题，比较像一个简化版 workflow engine。

给一组 task，每个 task 有 id、dependencies、action，dependency 完成以后才能执行当前 task。第一问比较简单，就是给 workflow，返回一个合法的 execution order，基本就是 topological sort，我用 indegree + queue 写的。

然后开始加 follow-up：现在不是返回顺序了，而是真的要执行这些 task，而且最多同时只能跑 K 个。这里我一开始想直接在原来的 BFS 上面改，后来发现 execution 完成时间不一样，不能简单一层一层跑。

后来的思路是维护：

• ready queue
• running tasks
• dependency state

一个 task 完成以后再 decrement children 的 indegree，变成 0 的放进 ready queue。

然后 interviewer 加了 failure。如果一个 task 失败，可以 retry 两次。如果最后还是失败，它下面依赖它的 task 都不能执行。我这里写的时候有个小 bug，一开始只把 direct children 标成 blocked，但是 descendants 还是有机会进 ready queue。后面自己跑 example 的时候发现了，又加了一次 propagation。

最后一个 follow-up 是：有些 task 会调用外部 API。第一次 call timeout 了，你不知道对面到底执行成功没有，这时候 retry 怎么办？

其实又绕回了前两轮的 idempotency。我回答 action 需要带 stable execution id，如果 external API 本身支持 idempotency key 就直接用；如果不支持，就需要针对这个 integration 做额外的 reconciliation / dedup。

这一轮算法本身不算难。我感觉他们故意选 workflow executor，是因为很容易从 topo sort 一直往真实 production system 加东西：

parallelism → failure → retry → dependency propagation → idempotency

整体感受

Plaid 这个 AI Tooling 岗和我一开始想的不太一样。Agent framework 本身反而不是重点，没有一直问 LangChain API 或者某个模型的细节。

他们更关心的是：

• AI workflow 怎么真的放进 production
• tool permission 怎么控制
• side effect 怎么保证安全
• retry / crash recovery / idempotency
• 哪些东西应该用 Agent，哪些其实不应该
• 最后这个产品有没有真的帮内部用户提高效率

感觉 AI experience + 很强的 backend / platform 基础会比较吃香。如果只是做过一些 RAG demo，可能第二轮开始就会比较难，因为很多 follow-up 最后其实都是 distributed system / security / production engineering。

Coding 也不是特别卷算法，但会从一个简单版本开始不断加现实条件。我个人感觉最难的反而是 system design，因为 interviewer 会一直逼你把“Agent platform”这个很虚的东西变成具体的 permission、state、API 和 failure behavior。