Agent 网络——Dharmesh Shah、Agent.ai + HubSpot CTO

摘要

• Dharmesh Shah 的核心判断是，Agent 时代很快会演变成多 Agent 网络：软件把任务委派给软件，“工具”可能收缩为原子级 Agent。 Agent.ai 是他的工作原型：拥有 130 万用户、3,000 名构建者和约 1,000 个已发布 Agent，均可通过 REST 和 MCP 调用。瓶颈将从创建 Agent 转向发现和路由 Agent，因为当时暴露的工具超过约 15–20 个后，模型质量就开始出现明显下滑。
• MCP 的重要性不在于它是完美协议，而在于它补上了让独立构建的系统彼此发现、互相调用所缺失的标准。 对于“OpenAPI 已经够用了”的质疑，Dharmesh 的回答是经验主义的：“the universe decided that this was useful”（这个世界已经决定它有用）。注册表、Agent 画像和新型 MCP 客户端，可能成为连接人类与自我描述软件、构成混合团队的基础设施。
• 正在形成的 Agent 经济是路由和评估市场，而不是“一个模型统治一切”。 Agent.ai 用户倾向于选择数字最大的模型，包括 GPT-4.5，而不是相信自动选择；但重复运行和人工评分可能显示，更便宜的模型能以低“多个数量级”的成本提供同等输出质量。因此，真正的机会在于工作证明式评估、模型路由，以及把每项任务匹配给合适能力和价格的市场。
• AI 代码生成强化了少做工程的理由，因为重构成本可能趋近于零，但也让产品泛滥更危险。 Dharmesh “宁愿少做工程，也不愿过度工程化”，因为技术债的回报相对可知，而推测性的抽象可能永远用不上。新的约束变成判断力：当功能几乎免费可构建时，团队可能变得“过于随意”，把复杂性转嫁给用户。
• 结果定价最适合结果客观可衡量、经济价值稳定的场景。 客服符合这一条件，因为企业知道每张已解决工单的大致成本，也能监测 CSAT 或类似服务水平；Logo 设计则不然，因为品味、迭代次数和价值差异极大。Dharmesh 认为，行业正在过度押注结果即服务，而许多客户可能更愿意低价购买工作，把其中的上涨空间留给自己。
• 长期来看，跨 Agent 记忆可能成为下一层平台，但粗粒度 OAuth 权限范围可能不够用。 Dharmesh 希望一个 Agent 学到的知识能够有选择地提供给另一个 Agent，最终提供给混合团队，而不必反复询问用户。他的 300 万封邮件案例把需求具体化：有用的 Agent 需要标签、时间窗口和每日限额等细粒度自然语言权限，而不是全有或全无的收件箱访问权。
• 知识图谱可能通过保留分块和 Top-X 向量检索丢失的关系来改进 RAG，但 Dharmesh 把这视为假设，而不是“图谱信仰”。 他提出的 NodeRank 会给图谱节点增加权威性或相关性信号，但主持人强调，图谱系统会变得复杂，评估规模仍然很小，一些收益只有在规模化后才会出现。Dharmesh 的务实答案是，只要系统能稳定地产生更好结果，晦涩或混乱也可以接受：“the one with the best results wins”（结果最好的那个赢）。

精读

1. 自然语言终于成为可执行接口

• Dharmesh 的 Agent 之路大约始于 20 年前的 Injenesoft：他设想过一种面向商业软件的自然语言接口。用户可以在飞机上离线时通过邮件发送指令；重新联网后，处理器解析指令、更新 CRM 或返回文件。实现时机过早，但他想要的交互模式一直保留至今。

• ChatSpot 是他在 ChatGPT 之后回到这一想法的产物。即使在 ChatGPT 3.5 时代，只要已知可能的意图，几个示例就能把自然语言转成结构化文本：“Now it actually works”（现在它真的能用了）。这让软件摆脱了那套被认为直观、实际却需要学习的点击、轻触和菜单语法。

• Agent 是下一步，因为同步聊天仍要求人持续参与。Dharmesh 想要的是：软件接收一个目标，执行多个步骤，之后再回来交付完成的工作——也就是离线邮件队列的现代版本。

2. 宽泛定义为多种 Agent 留出空间

• Dharmesh 故意提出一个令人不适的极简定义：“AI-powered software that accomplishes a goal. Period.”（能够完成目标的 AI 软件，仅此而已。）他不会把自主性或非确定性直接塞进定义，而是按多个维度对 Agent 分类，包括自主与非自主、确定性与非确定性、同步与异步，以及对话式与工作流式。

• 在他看来，BabyAGI、AutoGPT 和 Microsoft 的 AutoGen “way ahead of their time”（远远超前于时代）。它们假设模型已经具备当时尚未拥有的推理、规划和执行能力。因此，他把受追捧的技术前沿与商业上真正重要的“实用前沿”区分开：后者关注的是能否经过一定验证、反复解决一个离散问题。

• 主持人对“为什么是现在”的解释，包含更强的推理能力、更可靠的工具使用、MCP、更便宜更快速的推理、多样化模型、多 Agent 研究和 RL 微调。模型多样性很重要，因为切换模型可以跳出单一模型的性能盆地，而不是在其中无休止地优化。

• 他的底线仍然是必须使用 AI：没有 AI，原子单元就只是软件。Dharmesh 接受这样的反驳——数据库调用或 REST 函数因此不能算 Agent——但仍认为，把系统拆解为一个个可组合原语很有价值。

3. 原子 Agent 指向网络，而非单体

• Dharmesh 借用生物学提出问题：单细胞生物对应的 Agent 版本是什么？如果把工具视为原子 Agent，更高阶系统就可以拆解目标、通过网络进行委派：“Then it’s turtles all the way down”（如此一来，下面还是乌龟，一层接一层）。工具调用与多 Agent 协作的区别，最终主要会变成抽象层级的区别。

• 他的预测是，“Agent 之年”很快会被多 Agent 系统和网络接棒，甚至可能就在下一年。到了那时，发现、能力描述、委派和共享协议，比单个 Agent 对通用智能的幻觉更重要。

• 主持人把他的细胞类比延伸到人类通过 B device、Limitless 等可穿戴设备增强记忆。Dharmesh 自己的表述没那么拟人化：人、Agent、播客和想法都是巨大网络中的节点，而人生会在“收集点”和把它们连接成无法预先预测的组合之间交替。

4. 图谱可能找回向量检索丢失的上下文

• Dharmesh 贯穿 30 多年的数据库经历，从 IBM 的 IMS——本质上是带索引的键值存储——一路走到关系表、MongoDB 式文档和向量存储。他对图谱感兴趣，是因为图谱保留结构，不必把知识强行塞进行、列和外键，同时比 embedding 更容易检查。

• 他对图谱 RAG 的判断是有条件的：在 100 万份文档上做向量搜索，会返回语义上最匹配的结果，但分块可能同时丢掉整体图景及其中相关的维度。妥善捕捉的图谱可能保留有助于改进某些检索流程的关系——关键字是“可能”。

• 受 PageRank 启发，他尚未实现的 NodeRank 项目会根据指定的权威性定义，对任意图谱节点进行排名。在知识存储中，来源、贡献者专业度、受欢迎程度或任务相关性，都可以影响哪些节点值得更大权重，而不是把每个匹配分块一视同仁。

• 主持人的反驳是，机器学习从业者经常把知识图谱视为忌讳词：图谱供应商会陷入“图谱信仰”，复杂度爆炸，而小规模评估又看不到只有在规模化后才会显现的行为。Dharmesh 承认自己不知道图谱何时会变成过度工程化；他的实际标准是效用，即使图谱最终又成了一种不透明、有损的表示。

5. 技术债偿还成本低时，少做工程胜出

• Dharmesh 的基本规则是：边际成本很小时，就把事情做好。更难的决定，是是否要为不确定的未来需求构建可复用抽象；他的评估方式是“卡路里回报率”：列出可能路径，赋予粗略概率，再比较准备成本和未来预期收益。

• 如果不得不犯错，他选择少做工程。少做工程产生的债务，其利率相对可知：未来一个本应耗时 1 周的改动，可能变成 4 周。过度工程则是今天花费稀缺时间，押注一个可能永远不会发生的场景，同时放弃本可以构建的其他东西。

• 代码生成进一步把计算推向延后。随着大型代码库可以装进模型上下文、自动重构能力提升，修复一处捷径可能只需让模型运行 6 小时，而不是 60 分钟。如果修正成本趋近于零，那就“take on that cost”（把成本留到以后承担），现在继续构建。

• 主持人的反驳是，团队无法廉价地测试每一种架构：评估会消耗时间、人力和资源，而且有些方案只有在规模化后才有效。Dharmesh 的答案仍然取决于场景：在用例真正需要图遍历或社交图规模性能之前，关系型表示已经足够。

6. 廉价代码把稀缺性从工程转移到产品判断

• 接近零实现成本的阴暗面，是功能泛滥。Dharmesh 担心团队会在添加能力时变得“less discriminating”或“too promiscuous”（不那么挑剔，或过于随意），把更高复杂度留给用户和企业。过去有限的工程工时，曾经构成一种粗糙但有用的纪律。

• 代码生成已经从自动补全和 Tab 补全，压缩到函数、应用和产品。Dharmesh 看不到一个有原则的终点：模型可能生成包括 UI、API 和变现机制在内的平台，最终甚至接近一家拥有市场进入体系的完整软件公司。

• 只有当初级身份就是全部贡献时，初级工程师才会消失。能够与“carbon-based life forms”（碳基生命）沟通、和客户交流、理解产品的工程师，可以借助 AI 在名义职级之上工作。Dharmesh 的 14 岁孩子学习 Python，不是为了语法，而是为了积累关于系统、函数和抽象的持久理解。

• 他认为，AI 工程会从生成式 AI 知识与经典软件工程的交集里出现。Python 仍是他偏好的共同语言，配合 Cursor 使用；当 Bret Taylor 提议 AI 需要一门新语言时，Dharmesh 唯一的反驳很直接：“No, Bret. I don’t think we do.”（不，Bret，我不认为需要。）

7. MCP 胜在补上了足够多的缺失结构

• Dharmesh 称 MCP 是“one of the better things that’s happened in the world of AI”（AI 世界里发生过的更好事情之一）。它足够简单，普通工程师就能搭建；又足够结构化，能让模型发现和调用外部能力。有用且可采用的标准，比理论上的完美更重要。

• “OpenAPI 已经能描述 API”这一冷嘲式质疑值得保留。Dharmesh 喜欢 OpenAPI，但认为 MCP 更窄，也更贴合 LLM 的发现方式。如果 OpenAPI 已经满足需求，采用情况本应说明这一点；但现实是，“the universe decided that this was useful”（这个世界已经决定它有用）。MCP 可能会被取代，但它的采用速度说明了真实的边际价值。

• 下一步需要的是标准化注册表和目录，用来描述 Agent 与 MCP server 能做什么。Dharmesh 还预计，客户端会超越 Claude Desktop、Cursor 和传统聊天界面，让从未为彼此设计的系统也能在没有紧耦合的情况下组合起来。

• 他更喜欢消费标准，而不是创建标准，认为自己更擅长组合现有部件，而不是以权威身份强行制定协议。他设想的例外，是一个公益性的“Open Graph”，让人们能够在自己控制的范围内发布经过选择的个人数据。

8. 用户拥有数据仍是激励问题，而非协议问题

• Dharmesh 设想的 Open Graph，可以让个人发布一个自愿选择加入的记录——他的例子是 opengraph.org/dharmesh.json——而不是被困在 Meta 的社交图谱或 LinkedIn 的职业图谱中。一位主持人把话题引向 AT Protocol，也就是 Bluesky 背后的协议；这是一次把身份和用户数据与控制性域名分离的尝试。

• 障碍在于，单独讨论数据架构，“normies don’t care”（普通人不在乎）。Dharmesh 把隐私重新定义为一场交易，而非非黑即白的美德：人们经常用有限数据交换生产力或效用，但应当控制交换哪些数据、给谁，以及换回什么收益。

• LinkedIn 体现了这种冲突。主持人说，他们曾把自愿导出的联系人列表在内部合并；Dharmesh 则指出，LinkedIn 可能发现并阻止自动访问。当主持人提到爬取数据的诉讼时，他区分了非用户收集公开数据与账户持有人受服务条款约束这两种情况——后者仍可能失去访问权。

• 他的批评仍然有所保留：他是 LinkedIn 的重度用户，拥有超过 100 万粉丝，也尊重公司最初“成员优先”的逻辑。但 15–20 年前形成的立场，不必永远支撑“thou shalt not have the data”（你不得拥有这些数据）这样的规则。

9. 混合团队需要一个面向 Agent 的职业网络

• Dharmesh 认为，团队混合人类与软件是“inevitable”（不可避免的）。早期的混合团队把正式员工与承包商、办公室员工与远程员工组合在一起；下一版则会把碳基员工与 Agent 组合起来。Agent 仍然是软件，也应当自我披露，但可以像同事一样接收委派。

• 这一前提催生了 Agent.ai——一个面向 Agent 的职业网络。Agent 可以在网络上拥有存在和档案，而发现 Agent 则类似于通过职业网络进行招聘。

• Dharmesh 随后继续追问：由于有用的数字员工几乎不存在，这个网络还需要一个低代码创建平台。Agent.ai 已达到 130 万用户；约 3,000 人构建过某种 Agent，通常用于个人生产力，约 1,000 个 Agent 已经发布。

• 这个项目免费，目前由 Dharmesh 资助。他部分把它视为研究和基础设施，而不是一项已经完成的商业产品推广；但这些使用量提供了验证网络论点所需的实验、人工反馈和可调用供给。

10. 组合能力把 Agent 发现转化为经济杠杆

• Agent.ai 通过 REST API 和自身的 MCP server 暴露每一个已构建 Agent。一个密钥可以访问多个模型和获得补贴的能力，比如 Dharmesh 的 Twitter API 访问权，从而降低开发者测试想法的设置成本，不必分别安排每个供应商。

• 他最鲜明的组合案例从一个个人域名估值 Agent 开始。由于域名缺少类似 Zillow 的有效市场，该 Agent 会按词或顶级域名搜索公开的可比交易，然后返回估计价值、理由和支持性成交记录，而不是假装知道一个确定价格。

• 一个创业公司命名 Agent 可以在搜索二级市场挂牌时调用这个估值 Agent。如果估值 Agent 判断某个域名价值 $25,000，而 GoDaddy 挂牌价为 $5,000，组合系统就能发现表面上的套利机会。价值在于重新组合原本从未协调过的 Agent。

• 眼下的技术约束是上下文。Dharmesh 说，过去实用工具数量大约在 15–20 个，超过这个范围就会成为重大问题；直接暴露 1,000 个 Agent 不可行。缺失的中间层是“RAG for tools”（工具 RAG）：在编排开始前，根据用户提示选出一组合理的子集。

11. 确定性工作流与生成式界面可以共存

• Agent.ai 最初采用分步骤、低代码的确定性流程，部分原因是当时还没有能力足够强的推理模型。Dharmesh 的第二个理由至今仍成立：如果构建者知道所需步骤，“there’s literally no upside”（让模型重新发现流程并引入本可避免的偏差，完全没有收益）。

• 但交互仍应超越同步聊天。人不会把工作交给同事后一直盯着对方直到完成；Agent 同样需要队列、隐含响应时间和异步交接。

• Agent.ai 目前使用刻意原始的输入，以及接近“HTML 1.0”控件的 HTML 或标记输出。Dharmesh 不想无限扩张传统 UI 构建器，而是希望构建者先描述界面，通过生成式代码反复迭代，再把接受的结果保存为稳定的工作流动作，避免持续产生推理成本。

• 主持人把这与应用生成器和基于预制组件的函数调用之间尚未开发的中间地带联系起来：生成一个“Mad Libs”表单，把它固定下来，再让深度研究填充。主持人还提出，AI 最终可能发明超越复选框、单选按钮和下拉框的交互原语。

12. 工作证明可以在 Agent 市场取代声誉

• 与人类候选人不同，Agent 可以在被选中前反复评估。Agent.ai 可以让发布者提供 50 或 100 次试用调用，保留审计轨迹并公开使用历史。现有 Agent 已获得数万条评价，平均约 4.1 星，但 Dharmesh 认为直接任务评估是更强的信号。

• 一家公司可以根据真实工程问题生成 15–20 个示例，再测试 AI 软件工程师的代码和协作表现，类似于付费的人类候选人带回家作业。主持人的批评是，几乎所有人都认同评估重要，但“almost nobody actually does”（几乎没人真的会投入去做）。

• 对 Dharmesh 来说，OpenAI 重建 GPT Store 是必然事件，而不是 Agent.ai 特有的威胁。他的规则是“don’t compete with Sam”（不要和 Sam 竞争）；Agent.ai 则通过在供应商之间保持瑞士式中立来差异化：工作流的不同步骤可以分别使用写作、推理或图像生成模型。

• 用户仍然会选择界面上数字最大的模型，有时是 GPT-4.5，而不是相信“让系统自己选”。Dharmesh 正在测试：数千次相同运行加人工评分，能否把任务转给更便宜的模型，同时不产生可检测的质量损失。他愿意购买路由能力，而不是自己构建；Chai AI 的供应商市场和 DSPy 的评估优先路径，都体现了这一方向。

13. 结果即服务的适用范围比炒作所说的更窄

• Dharmesh 区分软件即服务和工作即服务：前者是人使用软件，后者是软件执行任务。结果即服务更进一步，按完成的结果收费，而不是按时间、使用量或执行的工作收费。

• 客服是最典型的适用场景，因为买方已经知道解决一张工单的大致成本。结果可以用 Net Promoter Score、CSAT 或明确的服务水平来判断；在高流量的一级支持中，一张成功解决的工单通常在经济价值上与另一张相近。

• 他认为行业正在过度押注这一案例。Logo 没有同样客观的终点：可能需要 5 次迭代，也可能需要 100 次；买方可能并不知道自己想要什么；而“weird taste”（奇怪的品味）也不在软件供应商控制之内。主持人分享的 99designs 经历把这一限制具体化：有很多有能力的设计师，却没有清晰的目标结果。

• Dharmesh 在 99designs 上的策略，是保证有人能拿到报酬，从而提高参与度。一个看似会收到 30–60 份投稿的项目，最终可能接近 200 份。但客户可能仍然更愿意低价购买工作，把成本与最终价值之间的差额留给自己，而不是通过结果定价放弃这部分套利空间。

14. AI 扩大工程分子的同时，归因仍然缺失

• Dharmesh 说，有意义的归因几乎不存在，因为掌握必要数据的各方没有动力公开这些数据。即便是付费搜索和分析系统，也比过去提供更少的、可以直接连接的信息，让人很难把一个结果归因到企业可能使用的所有输入。

• 一位主持人指出，一个结果可能有 18 个贡献输入；即使没有 AI，归因也已经很困难。

• Dharmesh 预测，web3 将以“它本来应该实现的方式”回归，通过可验证审计日志、归因和数字资产的部分所有权等实用原语实现。区块链带来存储或交易税，因此并不适用于所有事情；但他认为，合适的用例集合是有限，而不是为零。

• 在就业方面，Dharmesh 看好工程师，因为通常的自动化论证只盯着分母——数字工程师供给不断增长。他预计分子，即经济总价值和可由软件解决的问题数量，增长速度会更快。人类工程师获得更好的工具，也能处理过去不值得开发软件的工作。

• 就业形式仍可能分化。有些工程师留在组织内部，有些像自由职业者一样出售离散工作，还有些会构建通过市场获得收入的 Agent。经济单位会发生变化，但这不意味着工程价值会一对一消失。

15. 共享记忆需要比现有 OAuth 更细的权限

• Dharmesh 称长期记忆，尤其是跨 Agent 记忆，是“the next frontier”（下一片前沿）。ChatGPT 式记忆可以在一个系统内调取过去的事实，但当选择性复用能够改善体验时，用户不应当向 Agent 2、Agent N 和 Agent N+1 反复重复同样的“知识碎片”。

• 记忆还应存在于团队层面：一组选定的人和 Agent 可以共享状态，类似一个不对外公开的私有 Slack 频道。主持人把这与 Mem0、MemGPT——现在的 Letta——Zep 和 LangMem 联系起来，也提到语义、情景和背景记忆正在形成层级，其中“AI should sleep”（AI 应该睡觉）以巩固经验。

• 授权是尚未解决的对应问题。以日程安排为例，Agent 需要披露空闲时间或共享事件，却不能暴露无关的日历条目。OAuth 2.0 权限范围通常过于粗粒度，而且演进速度取决于供应商；Google 和其他既有巨头也未必有动力创建 Agent 所需的每一种细粒度权限。

• Dharmesh 的收件箱里有 300 万封邮件，并驱动着一个私有向量存储；但当一家创业公司要求完全访问时，他的回答是“hell no”（绝对不行）。可信中介可以接受自然语言政策——只允许选定标签、只允许近期邮件、每天不超过 50 封——然后释放最低限度的有用子集。

16. 领域、信念与有纪律的拒绝会在数十年间复利

• Dharmesh 买下 chat.com，是因为他最初认为 ChatGPT 是 OpenAI 底层平台的演示，应该有人用更友好的名字打造面向消费者的产品。OpenAI 发布插件后，他确认 ChatGPT 本身就是产品；由于不愿和 Sam Altman 竞争，他没有寻求传统的转售利润，而是主动提供域名并达成交易。

• 他仍拥有 agent.com、prompt.com 和 scout.ai，也拥有 crew.ai，同时愿意按成本价提供给相关公司。Dharmesh 预测，agent.com 最终可能值 $30 million–$50 million，甚至超过 chat.com 的 $15 million；他把 playground.com 卖给 Sahil 的公司换取股权，尽管自己也有跨模型 playground 的设想。

• 他“cards-face-up”（摊牌式）的购买风格牺牲了匿名性，却建立了卖方信任。他还投资了一家公司，试图把域名变成可分割、可交易、几乎即时结算并转移 DNS 的资产，目的是消除托管摩擦，改善市场低效。

• 当被问到是什么让他成为“fierce nerd”（狂热极客）时，Dharmesh 提到信念、耐力和一种特殊平衡：愿意比聪明的人更努力，但“only slightly stupider than people that are willing to work harder than me”（只比那些愿意比我更努力的人稍微笨一点）。竞争是一场游戏，不是战争；在 HubSpot 工作 18 年、即将进入第 19 年的他表示，预计还会再待 18 年。

17. 信念系于问题，策略可以随时丢弃

• Dharmesh 避免对产品或解决方案抱持教条。他把信念系在真正需要解决的问题上；当技术、时机或自身能力不足时，就把某种实现搁置。随着 AI 改变棋盘，他会重新查看积压的问题，再问一句“now is the time”（现在是不是时候）。

• 他主要通过 YouTube 保持跟进，经常一边写代码一边观看几小时。他平均约在凌晨 2:00 入睡，但称自己能睡 7 到 7.5 小时，也避免闹钟和早间会议。他想要的 Agent 包括从演讲中提取幻灯片，以及生成带时间戳的文字稿或合并片段。

• 最近让他印象最深的模型是“Gemini Flash Experimental, whatever they call it”（Gemini Flash Experimental，反正他们叫这个名字），因为它能编辑已有图像，而不是只能重新生成 Stable Diffusion。第一次测试是把 HubSpot Logo 的 O 换成甜甜圈；语义上成功了，但甜甜圈尺寸不对。

• 一位主持人给出暂定背景：Mostafa Mostafa 从 Meta 的 Lama 3 图像生成工作转到 Gemini，而该系统据传采用自回归生成，而非 diffusion。主持人认为，这一范式转变可能重新打开图像生成市场，并挑战 Photoshop 或 Canva；但这一说法明确仍是传闻，未经证实，也不是确认的架构信息。

18. “Sorry, I Must Pass”保护那些真正得到肯定的工作

• Dharmesh 于 2007 年首次写下“Sorry, I Must Pass”，并在 2022 年更新，用来解释自己为何拒绝请求，而不评判请求者或项目。每一个“是”必然意味着在别处说“不”；Derek Sivers 的标准——要么“hell yes”，要么拒绝——成为他抵御过载生活的默认防线。

• 他认为，内疚是心理学中效率最低的情绪之一。这篇文章让他可以亲自拒绝，而不是自动化回复，同时说明一项 15 分钟的帮忙、一次二度介绍或一次创业公司评审，仍然会消耗他已经分配出去的能力。

• 他的工作模式极度异步：基本没有电话，没有一对一 Zoom，只参加经过选择的团队会议。当时间由自己控制时，他愿意花 20 分钟写一份认真回答；同时保留把匿名化洞见重新用于模型、博客文章或 Dharmesh.ai 的权利。

• 他给 AI 工程社区的结语，又回到了 HubSpot 最初的 inbound marketing 核心：围绕受众解决问题，而不是围绕组织想要广泛发送信息的愿望解决问题。赚钱和获得乐趣可以与这一目标兼容，但持久价值来自“putting something useful in the world”（把有用的东西带到这个世界上），并相信更高效的市场会奖励这种慷慨。