Notion Custom Agents复盘：三年重写5次，Notion 历史上最成功的新功能之一

Notion 应该是最擅长做 Agent，而且是最成功的团队之一了。

Custom Agents 功能推出后，成为了 Notion 历史上转化率最高的新功能之一。而在正式发布之前，Notion 在三年时间里，前后推翻重写了 5 次 Agent 系统。

最近，Notion 的 AI 工程负责人 Sarah Sachs 和 技术负责人 Simon Last 在 Latent Space 的采访中，分享了 Notion 在 Agent 方向探索、转型的一些思考，很有意思。

• 别把你系统里不必要的复杂度暴露给模型，尽一切可能给它它想要的东西；

• Coding agent 是通往 AGI 的核心，一切都是 coding agent；

• Evals 不只是「测试」，是要理解模型往哪里走。理解模型能做什么、不能做什么，怎么定义 headroom，怎么定义好的用户旅程，这需要一种很难被定义的直觉和品味；

• MCP 是简单有效的东西，但 CLI 才是未来方向。能力和语言模型的使用要对齐，用语言来执行确定性任务，是一种浪费。

• 现在模型市场有一个很明显的「空挡」，在非常强但很贵和非常快但能力有限之间，中间地带几乎没有模型填满。

• 未来大部分流量将来自 Agent，而不是人类用户；

以下是访谈的精华内容。

01 

22 年就开始做 Custom Agents，

但模型不行 

主持人：Custom Agents 终于发布了，感觉怎么样？

Sarah：说实话，有点「延迟满足」的感觉。这个功能在 Alpha 阶段已经待了有一段时间，那时候一部分人在做上线前的最后确认，另一部分人已经在忙在做下一个版本了。正式发布的时候，反而得提醒自己回头看看，我们做了这么多事。不过这次用户反响很好。现在做 AI 工具比两三年前容易多了，用户不需要你解释太多，一看就懂。从免费试用转化的数据来看，这是我们历史上最成功的一次发布。

Simon：对我来说这次发布特别有意思，因为这大概是我们第四次或第五次重做这个功能了。

主持人：你们做这件事其实从 2022 年就开始了？

Simon：对，差不多是我们刚拿到 GPT-4 访问权限的时候。当时就想，把 Notion 所有的工具都接上去，让它在后台自动干活。那时候我们还在用「assistant」这个词，「agent」还没怎么流行。然后就一遍遍地试，一遍遍地发现时机还不成熟。

主持人：具体是哪里不成熟？

Simon：Function calling 还没出来之前，我们自己设计了一套 XML 格式的工具调用框架，然后试着 fine-tune 模型来用它，还要支持多轮对话。

Sarah：我们分别跟 Anthropic 和 OpenAI 都合作尝试过。当时工具调用这个概念都还不存在，完全是自己摸索。结果是，模型太弱，context 也太短，在这上面撞了很久的墙。一直有那种感觉，好像快要成了，但就是不够稳，没法变成一个真正好用的东西。

直到去年年初 Claude Sonnet 3.6、3.7 出来之后，我们才真正开始做现在这个 Agent，先发布了去年的版本，然后才有了这次的 Custom Agents。

主持人：三年重建了五个版本，每次在解决什么问题？

Simon：最早是 2022 年底，我们做的是一个 Coding Agent——思路是不做工具，直接让所有东西都是 JavaScript，给模型 JavaScript API，让它用代码调用工具。但那时候模型写代码太烂了，走不通。

然后转向工具调用的抽象。Function calling 还没出来，我们自己设计了一套 XML 格式，可以无损地映射到 Notion 的 block 数据结构。但这里有个大教训：我们太迁就 Notion 自己的数据模型了，而不是迁就模型想要的东西。 模型根本不认识这套 XML，你得在 prompt 里硬塞进去，非常不自然。

后来我们做了一个项目，专门创造了 Notion 风格的 Markdown，核心原则是，必须是模型认识的普通 Markdown，然后再加一些扩展，不需要无损转换，够用就好。这是一个很大的转变。

数据库查询这一层也有类似的故事。Notion API 的查询格式是一套复杂的 JSON，我们直接扔掉，改成了 SQLite——所有数据库都是 SQLite 表，模型可以直接写 SQL 查询。模型对 SQL 非常熟悉，效果立竿见影。顺带一提，这个改动并不是从零开始的，Notion 的数据库底层本来就已经在往 SQLite cluster 的方向迁移了，算是歪打正着。

核心教训是：别把你系统里不必要的复杂度暴露给模型，尽一切可能给它它想要的东西。

后来又经历了从 few-shot prompting 到纯工具定义的转变。以前所有人都在编辑同一个 prompt 字符串，顺序很重要，位置越靠前模型越听，只有五六个人有权限动那个文件。现在每个团队可以自己拥有自己的工具定义，有了完善的 eval 体系之后，大家可以独立迭代。这是我们在规模化上最大的一个杠杆。

当然也有新问题，比如两个工具取了同样的名字，Agent 就崩了。我们还发现了一个有意思的差异：Anthropic 的 Sonnet 遇到重名工具直接不行，OpenAI 的 GPT 会自己想办法处理。这是我们通过 eval 偶然发现的。

最近正在推进的是 progressive disclosure（渐进式披露），当工具数量超过一百个之后，不能一次性把所有工具都塞给模型，要让它能搜索和过滤工具。以前光是打个招呼就要消耗几千个 token，太慢了，而且质量也有问题，任何工程师随便加一个小众工具，都可能干扰整个模型的判断。

主持人：Custom Agents 比上一个版本晚了不少，主要卡在哪里？

Sarah：主要是可靠性。Custom Agents 是真正跑在后台的，不需要用户盯着，要求就高多了。而且权限设计非常复杂，这个 Agent 被分享在哪个 Slack 频道、能访问哪些文档、不同用户之间的权限交集怎么处理，光是把这套产品逻辑做对，就打了好几次。每件事做起来都挺难的。

02

Coding agent，

才是通往 AGI 的核心

主持人：你们在大模型能力不够的时候，怎么决定产品路线图？

Simon：我觉得这永远有个平衡要拿捏。一方面你要有点 AGI 信仰，要往前看，要为未来在建；另一方面又得持续交付有用的东西。我们的做法是同时跑多条线，维护已经上线的功能、打磨正在工作的新东西，同时保留几个「有点疯」的项目。

主持人：你们今天有哪些「AGI 项目」？哪些东西可能在 18 个月后人们会觉得这个可能会奏效？

Simon：18 个月是很长的时间。我觉得有一点越来越清晰的是：coding agent 是通往 AGI 的核心，一切都是 coding agent。令人兴奋的是，你的 Agent 可以自举自己的软件和能力，自己调试和维护。我们在这方面想了很多。

另一个我很兴奋的方向，是我们内部叫「软件工厂」（Software Factory）的东西。很多人在用这个词，基本意思是：能否创建一个尽可能自动化的工作流，用于开发、调试、合并、审查和维护代码库，里面有一堆 Agent 在协作？这会是什么样的？

主持人：那为什么花了三年半才做成？

Simon：推理模型是一部分原因，但我觉得真正让 Notion 与众不同的，是我们有两种关键技能。

第一个，是能快速判断自己是不是在逆流而上，你到底是在对抗模型的能力极限，还是其实是自己没有把正确的信息喂给模型、基础设施没搭好？这个判断本身就是一种直觉，需要培养。

第二个，是在判断出「没有逆流」之后，能看清楚河往哪个方向流，然后提前开始往那个方向建，哪怕现在还不完美，等到时机到了，你已经准备好了。

这两件事有时候看起来是矛盾的。比如我们当初在 fine-tune 工具调用模型，那时候这类模型根本还不存在。诀窍是不要在错误的方向上耗太久，但同时也要认识到，那个方向本身是有东西的。我们做过很多次「游错了方向」的事，Meeting Notes 功能在最终做对之前，我们做了好几个版本的语音转写方案，一直没找到正确的「姿势」。

主持人：有人说 Notion 只是 AI 的 wrapper？

Sarah：我把 Agent Lab 的那篇文章*发给了太多候选人，它已经是我 Chrome 自动填充里排名最靠前的网址了，这就是我们招人时说的「为什么 Notion 和 OpenAI 不一样，为什么我们不只是 wrapper」。

注：Latent Space 此前发表的一篇阐述 Agent 产品公司的文章，https://www.latent.space/p/agent-labs

Simon：我喜欢用 Datadog 和 AWS 来做类比。Datadog 离开 AWS 的云存储根本无法存在，这是基础。但 AWS 有自己的 CloudWatch，Datadog 依然做成了一家大公司，因为他们是理解「人们想要怎样的可观测性」这件事的专家。我们的专长是理解「人们想要怎样协作」。这才是我们真正的护城河，跟底层用什么工具无关。

Notion 一直是个极度横向的产品，我们的任务始终是平衡两种力量：一方面倾听用户想要什么，另一方面把这些需求拆解成好用的原语，让整个系统保持干净。我们的失败往往发生在我们太关注什么工具更酷的时候，那是我们速度最慢的时候，因为你还是需要聚焦在用户旅程上。比如我们每周五都会坐下来，看 token 消耗最多的 custom agent 对话记录 P99 指标，分析为什么没做好，然后砍掉一堆任务。

03

Evals 不只是「测试」，

是要理解模型往哪里走 

主持人：你们有没有注意到模型厂商的「秘密降级」？比如，高流量时段模型会突然变蠢？

Sarah：我们肯定注意到了不稳定性，特别是某些供应商在工作时间会变慢。质量方面也有一些有意思的发现，即使公司声称通过不同供应商卖的是同一个模型，无论是直接购买还是通过 Bedrock、Azure，我们确实会看到不同的质量表现，不一定是广告上说的那样。

Simon：有家公司甚至专门做了个 eval 在所有供应商之间跑，结果很明显地发现有人在偷偷做量化。

Sarah：我们雇佣了专门的第三方来帮我们搞清楚这些。我们想理解哪里在退化、哪里被优化了，有时候我们愿意接受适当的退化来换取延迟优化。我们的工作是确保有 eval 来理解对我们重要的变化。甚至在和实验室合作预发布模型时，他们会发多个快照给我们，确实发生过他们发来的版本不是我们想要的那个，最后他们根据我们的反馈调整了发布的快照，因为我们的反馈更偏企业知识工作，而不是 coding agent。

主持人：你们有没有那种「等着好模型出来就能成功」的失败 eval？

Sarah：我觉得大家说「evals」的时候，意思差得很远，就像说「测试」一样，不是只有单元测试。

我们大概分三层。第一层是回归测试，跑在 CI 里，必须在允许的随机误差范围内达到一定通过率。第二层是产品发布质量的 evals，我们有一张「成绩单」，每条用户旅程都有对应指标，必须达到 80% 到 90% 才能发布。

第三层是我们内部叫「frontier/headroom evals」的东西，主动把通过率目标设在 30%。这是我们过去两三个月和 Anthropic、OpenAI 一起推进的，因为我们发现自己的 evals 已经饱和了，模型一代代更新，我们只能说没变差，但说不出有什么洞察，对合作伙伴也没价值。

所以我们开始思考，Notion 的最后一道考题是什么，不是 Humanity's Last Exam，而是 Notion's Last Exam。现在我们有专门的人全职在做这件事：一个数据科学家、一个模型行为工程师、一个 eval 工程师，就专门负责那些我们只能通过 30% 的测试。

主持人：模型行为工程师（MBE）是个挺新的职能，怎么来的？

Sarah：这个职能最早叫数据专员，是 Simon 当时做 Google Sheets 相关工作时招的人，主要就是看数据，说这条好、那条不好。我们招了一个语言学博士肄业生和一个斯坦福比较文学应届生，他们做得非常好，慢慢就形成了一个新的职能方向。

他们以前主要是手动审查输出。大概一年半前，Simon 在白板上教他们怎么用 GitHub，说「如果数据专员学会提交代码，我们会快很多」。那是过去，现在写代码对他们来说完全不是障碍了。

这个角色往前走，是数据科学家、PM 和 Prompt 工程师的混合体。理解模型能做什么、不能做什么，怎么定义 headroom，怎么定义好的用户旅程，这需要一种很难被定义的直觉和品味，不一定是软件工程。我们很坚定地认为，这是一条独立的职业路径，我们更欢迎背景多元的人，不一定需要工程背景。

Simon：我们最近做了一件挺有意思的事，就是把整个 eval 系统做成了一个 agent harness。理论上，一个 Agent 可以端到端地完成：下载数据集、跑 eval、分析失败原因、调试、实现修复。人只需要在外层观察整个系统就够了。本质上就是把它变成了一个 coding agent 问题，用任何 coding agent 都可以，不绑定特定工具。

04

软件工程师以后的工作是管理 Agent

主持人：会不会有一天，Notion 就没有软件工程师了？

Simon：我觉得事情的发展方向都是连续的。三年前，人类在敲所有代码；然后有了自动补全；然后有 Agent 填行；现在 Agent 开始做更长程的任务，调试、修复、验证、提 PR、合并部署。我们只是在抽象阶梯上不断往上走，人类的角色越来越多地变成了「观察和维护外层系统」，一堆 Agent 在流水线里跑，什么东西出轨了？我需要批准什么？记忆机制有没有在正常工作？这本身是个很硬核的工程问题。

Sarah：就像机器学习工程师经历过的转变。我已经很久没看 PR 曲线了，以前这是核心工作，现在 auto research 能做。今年 Notion 的每个软件工程师都经历了某种身份危机，我们一位工程领导说，这就像每个经理经历过的那种危机：突然意识到自己写代码的能力，不如委派任务和切换上下文的能力重要。

Simon：但和管理者有一个关键区别，这实际上是非常深度的技术问题。人类很模糊，你没法把一个人类团队当成严谨系统来对待，PR 不能有 blocked 状态然后自动触发下一步。但 Agent 团队可以。这里面有很多有趣的技术严谨性，最终是一个技术设计问题。

主持人：你们正在构建的软件工厂，设计是什么样的？

Simon：我们在尝试很多不同的东西。最终目标是设计一个需要尽可能少人工干预、同时还能维持你在乎的那些不变性的系统。

我觉得有几个组件是关键的。第一个是某种规格层（specification layer）。你需要一个地方来存放规格，人可读、可查看。最简单的做法就是直接提交 Markdown 文件，这挺好用的。规格的自然栖息地当然是 Notion，可以是一个页面数据库。

第二个是自验证循环。你需要非常好的测试层，这是个很深的问题，但做对了非常关键。

第三个是 bug 的工作流。一个 bug 出现了，它怎么流入系统？是某个子 Agent 在处理吗？它怎么提 PR？PR 怎么被审查和合并？这是整个流程和过程的设计问题。

05

MCP 够用，

但 CLI 才是未来 

主持人：MCP、CLI，现在你们怎么看这两个方向？

Simon：我对 CLI 很看好。CLI 跑在终端环境里，天然有一些额外能力，可以分页、渐进式展示，不用一次性暴露所有工具。更关键的是，它是自举的：如果出了问题，Agent 可以在同一个环境里自己调试、自己修。

今天早上我看到一条推文，有人说他的 Agent 没有浏览器工具，就让它自己写了一个，100 行代码，包了一下 Chromium API，搞定了。如果出 bug，它立即自己修。但如果你用的是 Chrome DevTools MCP，transport 一旦出问题，Agent 就完全没有浏览器了，自己也修不了，这是根本性的区别。

MCP 也有它的价值，特别适合那种你想要一个轻量、权限收得很紧的 Agent 的场景。MCP 的权限模型非常清晰，你能做的就是调用工具，仅此而已。CLI 在权限这块反而更模糊，API token 怎么加密、怎么防止泄露，这些都是真实存在的问题。

CLI 我很看好，MCP 在特定场景下也很好，它是那种简单有效的东西。

Sarah：我想补充两点。第一是，Notion 作为企业工作的系统级记录工具，只要有人在用 MCP，我们就会持续支持我们的 MCP，这是我们的承诺，跟我们自己的偏好无关。

第二，我最近一直在思考一件事：能力和语言模型的使用要对齐。用语言来执行确定性任务，是一种浪费。 我们的 Custom Agents 是按用量计费的，如果一个任务可以用代码确定性地完成，那就用代码，一次性搞定，不要每次都让语言模型绕一圈再去调 MCP，还要反复付 token 费用，而且在 cache 窗口之外的话，每次都要重新付，完全没必要。

主持人：你们内部怎么决定什么时候用 MCP、什么时候自己建？

Simon：搜索是最典型的例子。我们在 Notion 里集成了 Slack、Linear、JIRA 的搜索，但我们没有用这些平台提供的搜索 MCP，而是自己建的。原因是搜索对我们 Agent 的执行路径太关键了，我们需要对质量有更直接的控制。

比如 GitHub 和 Linear 的集成用的是 MCP，但 Slack、Mail 和 Calendar 是自己建的，在这些工具上我们花了大量时间精调每一个工具的行为，也建了 trigger 系统，而 trigger 这个东西，MCP 协议里根本没有对应的概念。

我们内部有一套统一的抽象：什么是工具、什么是 Agent、什么是 completion call，MCP 只是其中一种集成类型。这是在 AI 时代唯一可行的做法，因为一切都在变，你必须能随时换掉底层。我们大概重建了五次框架，每次都是在想：这个新东西的抽象应该是什么？保持最简单、最笨的抽象，让不同的东西都能映射进来。

主持人：Custom Agents 的界面设计，你们做了一个叫「Flippy」的东西？

Simon：对。我们一开始的设计是：设置页是主页面，然后你可以在里面测试 Agent。后来我们发现，这个思路是错的。AGI 的思路应该是：它就是一个 Agent，它可以自己设置自己、自己测试自己、自己跑工作流。所以我们把它翻转了，主页面是对话界面，设置是一个侧边栏，预览 Agent 正在做的修改，你可以查看，也可以手动调整。但我们希望从设计上就让你不需要手动改任何设置，直接跟它说话就够了。

Sarah：这个改动是 launch blocking 的，因为我们有很多早期用户已经习惯了旧的交互方式。为了这个改动我们延迟发布了差不多一个月。但整个团队都很兴奋，因为它确实好太多了。做这个的是三个来自三个不同团队的工程师，我们就是把人拼在一起，没有人抱怨，没有经理抱怨，直接搞定发布。

Custom Agents 默认没有任何权限，你必须明确授权它能做什么。这正是你能信任它在后台跑的原因，你知道它能读邮件但不能发邮件，这种清晰感很重要。它不能修改自己的权限，但如果出了问题，你可以点修复按钮，进入同步对话模式，看着它做什么，确认之后才生效。

06

确保用户用的是「对的工具」，

而不是最贵的工具 

主持人：Notion Credits 这套定价是怎么设计出来的？

Sarah：我们没法直接用 token 数量来计费，因为不是所有东西都按 token 收费。我们自己部署的开源模型跑在 GPU 上，网页搜索的计费方式不一样，沙箱环境也不一样。所以我们需要一个比 token 更高一层的抽象，Credits 就是这个抽象层。同时它也让企业销售动作更顺畅，企业客户可以按量采购、享受折扣，这套逻辑很好理解。

背后还有一个更重要的考量是：如果我们不做用量计费，某些功能根本没办法存在。举个例子，数据库的 autofill 功能很快会变成 agentic 的，但如果每一个 autofill 操作都要跑一个 Agent，用最贵的模型跑每一个数据库格，那会是天文数字的成本，直接把公司搞垮。用量计费让愿意付更多的用户有渠道付，同时不把这个成本强加给所有人。

主持人：所有 token 的价值不一样，但你们收费差不多一样，这个问题怎么看？

Sarah：我们试过按任务价值收费，也试过按 Agent 运行次数收费，但发现复杂度最终还是映射回 token 用量，绕了一圈又回来了，还更复杂。

我们真正在意的，是确保用户用的是「对的工具」，而不是最贵的工具。这就是 Auto 模式的意义，不是最便宜的模型，而是最适合这个任务的模型。我们花了很多精力在做这件事，产品里甚至有一个提示，告诉你当前选的模型贵不贵。在 custom agent 场景里，用户不在乎速度，因为是异步的，所以 Haiku 更快这个优势完全失效，我们需要用别的方式引导用户做合理的选择。

类比一下：我来自 Robinhood，你可以花很多时间自己选股，也可以买指数基金，也可以用 robo-advisor。我们某种程度上就是那个 robo-advisor，我们有很多人在研究什么模型最适合什么任务。我们现在用 Auto 不是为了赚更多钱，而是为了减少不必要的消耗。

Simon：我们不像模型厂商那样，天然有动机让你用越多越贵的模型越好。我们希望的是：如果一个任务可以用代码确定性地完成，那就直接跑代码，连 Agent 都不用启动。让 Agent 把自己的工作自动化掉，对我们来说是个好结果。

另外，现在模型市场有一个很明显的「空挡」，在非常强但很贵和非常快但能力有限之间，中间地带几乎没有模型填满。大家都扎堆在两端，Haiku 其实也没便宜多少。我们在和一些开源模型实验室合作，思考 Notion's Last Exam 这些模型能做到什么程度，就是想把这个「智能-价格-延迟」三角的中间填满，给用户真正合适的选择。

07

新功能和新产品，

不能全靠内部黑客松 

主持人：Sarah，你怎么管理团队？

Sarah：我很清楚地意识到，我的工作不是做想法的人或者技术专家，而是让每个人都清楚目标是什么，有资源帮他们决定优先级，同时有渠道让他们把自己认为重要的事推上来。

在 AI 团队里，几乎所有最好的想法都来自工程师的原型——因为他们看到了某个用户问题，然后动手做了出来。如果所有想法都必须先过我和产品负责人的「嗅觉测试」，那是对团队的极大浪费。

所以我不把工程领导力理解成一种层级关系。我们愿意根据实际结果随时调整方向。我们的 Agent harness 大概重建了三四次，每次重建都意味着有人要删掉自己写的代码。在很多公司，这会产生很大的摩擦，但在 Notion 不会。新人加入，看到这里没有「我写的代码不能动」的文化，自然也不会去做那个人。这种文化直接来自 Simon 和 Ivan，他们非常开放。

Simon：我的角色更多是往前看一步，确保我们在正确的能力方向上建东西，同时做原型。核心就是不断地重新开始，这是个新东西，如果我们从头想，应该怎么做？大概每六个月我就会做一次这样的循环。

主持人：你们有内部黑客松吗？

Sarah：有两种形式。一种是我们有一批资深工程师，会轮流进入我们称之为「Simon 漩涡」的状态，高速推进、方向每天都可能变，类似一个 Skunk Works 实验室（洛克希德公司的臭鼬工厂模式）。这个不需要黑客松，需要的是信任度够高、能随时进出的工程师。管理边界也很松，你名义上汇报给 A，但现在在给 B 干活，这很正常。我们招经理时，重要的是他们不在乎这个，因为我们在发布后才形成工作结构，不是提前定好。

另一种是全公司黑客松。我们上周刚办了一次，今天早上做了 demo day。这个更多是给没有直接参与 AI 项目的同事，让他们有时间停下来学习，体验一下用 Custom Agents 能做什么。我们还专门设了一个环节，鼓励全公司所有人从零开始跟着博客教程搭一个 Agent 工具循环——我们希望公司里每个人都用过 Claude Code 或者他们喜欢的 coding agent，理解那个基础。

Simon：有点讽刺地说，我们构建的每个东西在「毕业」、穿上正装、有产品运营 rollout、有专属数据科学家之前，都有点像黑客松。黑客松对提升整体水位很重要，但如果那是你唯一能建新东西的方式，你就完了。在 AI 时代，杠杆越来越多地积累在最好奇、最兴奋的人身上。如果有人周末在原型一个他很兴奋的东西，那才应该是我们主要在做的事，而不是等着每季度排期一次的黑客松。

图片生成功能就是这么来的。这个功能一直是个「有了更好」的东西，优先级不明确，工作量也不小。然后数据库团队的 Jimmy 说，我真的很想做封面图的图片生成。我们说，你想做就做，我们全力支持。给他接了 Gemini 的权限、token 用量追踪、eval 支持，全套资源。然后这个功能就做出来了。这就是为什么做领导不能有 ego，这就是我们的工作方式。

主持人：你们团队现在多大？

Sarah：我管理的是「核心 AI 能力和基础设施」团队，大概 50 人。然后有合作团队负责「包装」。比如 corner chat、custom agents、meeting notes 怎么呈现，那是另外 30-40 人。

每个做产品服务的团队都拥有 Agent 交互的工具。做 CRDT 离线模式的团队，同时也是处理两个 Agent 编辑冲突块的团队——本质上是同一个问题。做底层 SQL 引擎的团队，同时也是负责 Agent 怎么跑 SQL 查询并保证性能的团队。所以从这个角度，任何做产品工程的人，都被要求同时为人类客户和 Agent 客户 work。因为随着时间推移，我们大部分的流量会来自使用我们界面的 Agent，而不是人类。我们的目标是让整个产品 org 都在为 Agent 而建。

文章来自于"Founder Park"，作者 "Founder Park"。