创业者闭门探讨：Make for Agent ，其实还是 Make for Human

本文作者「马多灵」，极客公园资深研究员。「Make for Agent」主题闭门 Meetup 的主持人。

上周六，我们组织了一场闭门 Meetup，主题是：Make for Agent 的产品应该怎么做？面向一线的 Agent 创业者和 Builders。

原本规划的议题是以「Agent IM → Agent 协作 / Workspace → Agent Habitat」，但在实际交流中，我们发现，大家关于第一层 Agent IM 的探讨花费了大部分的时间。这也传递出了当下 Agent 创业中一个非常实际的信号：当前业内做 agent 产品的真实卡点并不在一些远大的前景上，反而在离人最近的入口、身份、权限、上下文和控制感。

甚至，连「产品的用户不再是人」这个说法也需要打个问号。核心变化可能不再是当用户从 Human 变成了 Agent，而是 Human-AI 协作中的「责任链」被重新拆开了。

印象最深的，是来自现场的一位创业者感慨：「四五月份其实挺无聊的，因为大家太共识了。但今天交流发现，大家其实没什么共识，只有宏观上共识，在微观上差异很大。」

宏观共识太便宜了，大家都同意工作流会变、个人会被放大。都对，但没什么用。有价值的，其实是这场交流中的一些微观分歧：

• Agent 到底要不要 IM？

• 人类到底管目标、过程还是结果？

• Agent 是否应该拥有持续身份？

• 企业客户买的是效率，还是管控？

• 什么任务应该用 App，什么任务才值得上 Agent？

• Agent 之间通信时，传的是消息、意图、状态，还是责任？

• 当 Agent 出错时，是用户负责、产品负责、模型负责，还是组织负责？

以下，是这次闭门交流中的部分精华内容。希望能抛砖引玉，给大家带来一些新的思考。

⬆️关注 Founder Park，最及时最干货的创业分享

Meetup是「AI 产品市集」的线下延伸活动，每期聚焦一个垂直赛道，邀请一线创业者、资深从业者与核心用户，围绕产品的应用现状及未来演进，进行集中体验与闭门研讨。

活动参与者均来自「AI 产品市集」飞书群。「AI 产品市集」已经面向行业推荐了超 200 个 AI 产品，聚集了包括产品人、开发者、创始人、投资人在内的超过 23000 位 AI 行业从业者。

欢迎希望参与下一期 Meetup 活动的 AI 从业者、开发人员和创业者，飞书扫码加群：

01Agent 不需要像人一样聊天，但它需要被追责

现场争论最久的问题，是 Agent 之间到底需不需要「即时通信」。

一开始，大家其实并没有在同一个问题上争论。有人从产品形态出发：Agent 要不要被拉进群？要不要像同事一样在 IM 里出现？要不要跟人一起开会、看文档、接收图片和文件？一位做 AI Workspace 的创业者给出的理由很直接：

「AI 其实需要的是 context，人需要的是人与人之间的交流协作……AI 不需要一个 IM，其实 IM 是人需要的，因为人在过去 30 年里面，他的协作可能都是发生在 IM 上的。」

这个观点，其实是把第一层问题解释清楚了：IM对 Agent 来说不是目的，而是上下文入口。在现有的组织里，很多真实工作不是发生在结构化数据库里，更多是发生在群聊、会议、文件、转发、私聊、口头承诺和临时对齐里。IM 沉淀了组织里大量未被正式命名的 Context。Agent 如果进不去这些空间，就很难真正成为个人助理或组织协作者。

但另一边很快反驳：这并不意味着 Agent 需要人类式聊天。有创业者直接抛出暴论：

「Agent 不需要即时通信，需要即时通信的是人。现在 Agent 都在兼容人，因为人看不懂 Agent 之间是怎么样通信的，所以需要用到我们人类的工具、文档以及 IM。」

因为如果 Agent 之间只是为了交换状态、传递事件、调用工具、交接任务，那它们确实不需要寒暄、表情、已读未回，也不需要复制人类群聊里的低效噪音。

现场一位做了 22 年即时通讯、做过多个十亿级 IM 平台的创业者，直接把问题重新拆开来看：

「即时通讯里其实有最核心的两个东西，第一个是寻址……另外一个是 reliable，我有一条消息要 deliver 给你，你是确定、一定以及肯定能收到的。」

大家对即时通讯本身的理解是存在差异的。随后，现场又把这个问题往前推进了一步：

「Agent 之间不需要即时通信，不需要自然语言之间的这种即时通信……这个问题我个人的理解是，人需不需要看到 Agent 之间即时通信？这个是产品形态的问题。」

这句话几乎重新校正整个问题。

真正该问的不是 Agent 要不要即时通信，而是：人需不需要看见 Agent 的即时通信？我的判断是：大多数时候不需要，但关键时刻必须能看见。这不是一个二选一的问题，更多是一个产品层的设计决策。

Agent 之间的日常通信可以完全退到后台——协议、事件、任务队列、API 调用，人不需要盯着每一条消息。但当 Agent 要做一个不可逆的动作、要越过某个权限边界、或者出了问题需要溯源时，人必须能调出完整的通信记录，看清楚谁授权了什么、谁把什么转包给了谁。

换句话说，Agent 通信的可见性不是一个开关，更多是一个可调节的产品层。如果人需要看见，那通信就不只是系统内部的消息传递，是一种产品界面，一种解释机制，一种让用户感到「我知道它在干活」的控制感；如果人不需要看见，Agent 间通信完全可以退到协议、事件、任务队列、API 调用或文档引用里。

所以 Agent 不一定需要 IM 产品，但一定需要通信基础设施：寻址、可靠送达、事件总线、状态同步、上下文引用。更重要的是，它需要一种可追责的通信。如果一个 Agent 给另一个 Agent 发消息，却没有携带任务边界、权限范围、上下文来源、失败处理和结果验收方式，那它不是协作，只是把不确定性转包出去。

Agent 不需要社交型IM，但需要责任型通信；用户不一定需要参与通信，但可能需要看见通信。人类 IM 的核心是表达和关系；Agent 通信的核心应该是授权、状态、上下文和可追责。至于这些通信要不要被展示给人，则取决于产品要给用户多少控制感。

02真正的问题不是「通信」，而是「身份」

在现场讨论里，最深的一层其实不是聚焦在 IM，而是再近一步，Agent 身份。

一位创业者举了 GitHub 的例子：今天我们让 AI 访问 GitHub，常见方式是给它 personal access token，或者用 OAuth 授权。但如果 AI 真的是一个可协作的执行单元，它是不是应该像一个真实成员一样，被邀请进 GitHub organization 或 repository？他描述了的做法是：给每个 AI 一个邮箱，让它像人一样收到 GitHub 邀请，自己打开浏览器，自己加入仓库，自己拉代码，自己开始开发。这件事听起来像拟人化，但背后的关键不是像人，而是独立身份。

「如果这个 AI 拿你的 key，然后把事情搞砸了，那这个事情应该算谁的？」

没有独立身份，就没有细粒度权限；没有细粒度权限，就没有清晰责任；没有清晰责任，Agent 越能干，组织越不敢用。

「人是有这种社会契约的，AI 其实是没有的。」

当然，这里还有一个更细的区别是：人会变，Agent 也会变，但变的方式不一样。

「人类社会里面人是会变的，人会变分成人的技能会变，人的记忆会变，还有人的心思会变，还有人对一个人的看法也会变。」

Agent 当然也会被更新、被追加记忆、被改 prompt、被换模型、被装上新的 skill。但目前看，很多 Agent 的变化并不本质：它可能记住了你的名字、一次活动、一个偏好，却不一定真的形成对你的持续理解，也不一定能把关系、心思、组织角色和历史互动转化成稳定判断。它们在更新状态，但未必在形成身份。这也是为什么身份和权限不能只做成账号系统。账号只是入口，真正难的是让一个非人执行体在变化中保持可理解、可治理、可追责。人进入组织，不只是拿到账号和权限。人背后有劳动关系、法律身份、社会信用、职级、汇报链条、同事评价等等。AI 没有这些默认契约。所以当 AI 拥有邮箱、账号、浏览器、银行卡、代码仓库权限时，产品不能只问「它能不能完成任务」，必须问：

• 它代表谁行动？

• 它的权限来自谁？

• 它的行为如何被记录？

• 它泄露信息时算谁的事故？

• 它造成损失时谁承担？

在现场，一位创业者还提到一个很典型的企业事故：某个 AI 功能把年终奖名单发到了公司大群。这就不是模型能力的问题了，这是身份和权限问题。

Make for Agent 的第一性问题不是界面，是身份系统，即一个非人执行体如何在组织里获得有限身份、有限权限和有限责任。

03人类介入不是「什么时候」，而是「管什么」

现场讨论的一个议题是：人类应该在什么时机介入 Agent 的协作流程？

大家的共识是：人对 Agent 的介入，不要再问什么时候介入，应该问「人类介入后管什么」。有创业者提到，过早介入会让 Agent 无法发挥；过晚介入又会导致交付结果无人兜底。因为在人类社会里，即使你是用 Agent 做的，最后老板 blame 的还是你。

有人从产品经理视角给了一个例子：

「我永远给我的 Agent 的要求就是：你去写代码，你不要跟我确认任何东西，你只给我看结果……你怎么干我不管，最终给我结果就行。」

但他也补充：对于开发者来说，技术方案、代码结构、中间环节可能都需要介入。所以问题不是一个统一时机，更多是不同角色在不同任务上需要不同程度的控制感。

「人应该什么时机介入？这个问题也是有问题的。介入不应该由时机去判断，而是应该讨论你该在什么事情上介入。」

这是关于 Human-in-the-loop 讨论的关键。过去很多 Human-in-the-loop 的设计，都默认人是在流程中间做审批。Agent 做一步，人看一眼；Agent 做一步，人点确认。看似安全，实际很容易把 Agent 退化成一个高级牛马。但如果 Agent 真正开始承担任务，人类就不可能、也不应该盯住每一个中间动作。中间过程可能太快、太碎、太长，也太不适合用人类注意力来监控。人真正该管是这三件事：

• 目标：到底要完成什么，不要完成什么；

• 权力边界：可以访问什么、修改什么、代表谁行动到什么程度；

• 结果验收：这个结果是否符合意图，是否可以进入真实世界；

引用游戏中一个的概念是：空气墙。

「开放世界的游戏里会有空气墙，你不走到坑前、门前你就不知道过不去……对 AI 来讲需要的是这样的，它只有在撞上的时候才会感知到这地方有限制，而不能一上来就限制它的发挥。」

边界不一定要以「持续审批」的形式出现。更好的 Agent 产品，不是让人类随时盯着它，而是在敏感动作、越权行为、不可逆操作、外部发送、资金流动、公开发布时设置空气墙，让 Agent 在可控空间内自由探索，在关键边界处被拦下、升级、请求授权。

Human-in-the-loop 不应该是「人在流程里」，准确的说是「人在责任链的关键断点上」。

控制感是产品需要提供给用户的核心能力，但它应该是可调节的，不同用户、不同任务、不同风险水平，对控制感的需求完全不同。产品设计要做的不是规定同一种介入方式，是把控制感做成可调节的产品层：可见度、确认点、空气墙、日志、回放、权限边界和异常升级。

04Make for Agent 的生意，仍然是 Make for Human

现场探讨的一个议题是「当 Agent 成为主要使用者，产品的商业模式应该面向谁设计？」大家给了一个很现实的判断：口号可以是 Make for Agent，生意仍然是 Make for Human。

「如果最后买单的是人，他要的一定是控制。」（即便我们现场提到多次 Context not control，大家也都认可）

很多协作产品最后都会长成权限、管理流程、报表、薪酬这些东西。因为 Agent 不付钱，人付钱、企业付钱、组织里的某个预算负责人付钱。更重要的是，付钱的人买的是控制感。协作软件发展到最后，几乎都会长出权限、流程、审计、报表。因为企业客户真正购买的是可治理性。越靠近生产系统，越不可能只卖效率，必须同时卖责任边界。这也解释了为什么目前真正赚钱的 Agent 产品，最确定的一类仍然是 Vibe Coding。

「真正能够产生一些效果的产品……也只有一类生产力工具现在是赚钱的，叫 Vibe Coding。」

为什么是 Coding？软件工程已经提前准备好了责任基础设施。Git、PR、CI、测试、review、rollback、diff，这些东西让 Agent 的行动可以被框住、看见、撤销、追责。

一个 Coding Agent 改坏了代码，至少还有版本控制、测试和 review 把错误挡在生产环境之外。如果换到报销、招聘、合同、投放、金融、医疗、公司内部权限系统，情况完全不同。

判断一个场景是否适合 Agent，不是看 Agent 能不能做，而是看这个场景有没有足够好的责任容器。如果没有，Agent 做得越多，组织越焦虑。能用 App 解决，就用 App。能用规则解决，就用规则。能用自动化脚本解决，就用脚本。Agent 适合的不是所有任务，而是那些目标相对明确、路径不完全确定、需要动态上下文判断、且允许一定探索空间的问题。

05企业 AI 落地的瓶颈不是模型，是上下文和想象力

在企业落地方向，现场一个有意思的判断是：Agent 在公司里跑不起来，很多时候不是模型不够强，是人和组织都还不够 AI native。

「目前看起来很大的一个卡点就是在公司的业务，人没有那么 AI native……他想象空间是有限的，他可能不太清楚说我在这样的一个 IM 产品里面到底怎么样去用它。」

企业里的上下文，比个人场景复杂太多。个人用 Agent，很多上下文在脑子里。你知道自己想要什么，知道哪些文件重要，知道哪些输出能接受，知道失败了怎么补救。企业用 Agent，上下文散落在权限系统、知识库、飞书群、历史文档、CRM、代码库、业务流程、组织政治和未写下来的默契里。

现场，我们抛出了一个框架：

「Context is infrastructure. 分成三层：data context、knowledge context、identity context。」

第一层是用户说了什么、做了什么；第二层是组织隐性知识、协作共识和项目背景；第三层是角色、风格、价值偏好，以及那些没有明说但会影响判断的身份信息。这三层 context，决定了 Agent 能不能真正进入生产。

现场，另一位企业实践者补充了一个很好的说法：群聊是人的 context，但 AI 要执行，需要的是干净上下文。

「群聊里面 90% 都是 AI 不需要知道的信息……要把有用的信息提炼出来，真正变成一个个小项目进行执行。」

这其实也把 Agent Workspace 的核心讲清楚了。Agent 不是把所有聊天记录吃进去就能干活。它需要过滤、提炼、结构化、共识化。它需要知道什么是噪音，什么是任务，什么是背景，什么是边界，什么是最新状态。所以「demo 很多，真正进生产的很少」不是偶然。Demo 的特点是上下文被精心摆好，边界被人为缩窄，失败成本被隐藏。但生产系统的特点正好相反：上下文脏、边界乱、责任重、失败不可爱。

让 Agent 进入生产，不是喂更多数据，更多是先建立上下文基础设施。Data context、knowledge context、identity context 三层都需要被显式化、结构化、可治理。Agent 需要的上下文和人类协作沉淀的上下文不是同一套东西，前者需要干净、结构化、有边界；后者天然是嘈杂、松散、充满隐性的。产品设计要在两者之间做翻译和过滤，而不是简单地把群聊丢给 Agent。

06最危险的误判：把 Agent 当新人

在我们的现场讨论，非常有意思的观点是：

「把 Agent 当人看是对的，但是把 Agent 当人看是错的。」

这个观点其实同时指出了两个陷阱。第一个陷阱，是把 Agent 当工具。如果只把 Agent 当工具，就会低估它的自主性、连续性、上下文迁移能力和任务承担能力。你会一直试图用按钮、菜单、表单去控制它，最后得到一个被阉割的自动化系统；第二个陷阱，是把 Agent 当新人。如果把 Agent 当新人，就会下意识套用人类组织的协作习惯：拉群、对齐、汇报、确认、寒暄、角色扮演、上级审批。你会得到一个表面像团队、实际低效混乱的拟人化剧场。Agent 既不是传统工具，也不是组织新人，更像是一种新的执行单元：可以接收目标，调用工具，携带上下文，拆解任务，生成中间状态，并把结果交还给责任人。

在产品设计层面，不要只问「Agent 的界面是什么」，更多要思考「Agent 在责任链里的位置是什么」。它什么时候是工具，什么时候是代理人，什么时候是协作者，什么时候只是一个后台进程？它能否代表用户说话？能否代表用户花钱？能否邀请另一个 Agent？能否修改共享文档？能否把结果发给外部客户？每一个「能否」，背后都不是功能问题，是授权问题。

07产品也要讲究 Agent 友好度：不只是服务人，也要尊重 Agent 的工作方式

讨论到后半段时，现场出现了一个容易被忽略但很重要的视角：即使最终付费者和责任承担者仍然是人，产品也不能只按人的习惯来设计。有人说：

「除了人的需求之外，也要去尊重 Agent 的主体性的需求。」

这个说法其实指向的是非常实际的产品问题。比如，流式输出。人喜欢看到一个字一个字往外蹦，因为这能缓解等待焦虑，让人确认它还在干活。但从 Agent 自身的工作方式看，它未必天然需要流式输出。更像是一次性生成、一次性返回，然后由系统决定如何展示给人。所以 Agent 友好度不是讨好 Agent，是承认 Agent 和人的交互节奏、信息处理方式、输入输出结构不同。现场把 Agent 友好度拆成了几个很具体的点：

• 接口友好：能不能 CLI？能不能通过文本、API、文件、事件流接入？

• 多模态友好：当 Agent 需要图片、语音、视频、传感器输入时，产品能不能提供合适的输入形态？

• 上下文经济性：不能把所有历史记录、所有文档、所有群聊都一股脑塞给 Agent。窗口有限，注意力有限，成本也有限。

• 局限性友好：产品要知道 Agent 不是全知全能的，它需要被提供经过筛选、压缩、结构化的上下文。

面向人的设计要满足控制感，面向 Agent 的设计要满足经济性和主体性。前者回答「人如何放心把权力让出去」，后者回答「Agent 如何在不被人类界面拖累的情况下完成任务」。Make for Agent 不是把人类 UI 改成 Agent UI，而是在同一个产品里同时处理两种完全不同的需求：人需要理解、控制、确认和负责；Agent 需要结构化输入、明确权限、低噪声上下文和可执行接口。

08Make for Agent，其实是 Make for Responsibility

最后一个开放式探讨的问题是：下一代 AI 产品应该如何设计？我们应该创造什么样的产品？在这场 Meetup 中，没有给出现成答案，但至少给了我们七点产品洞察。按照「先想清楚 Agent 是谁，再想它怎么通信，再想人怎么介入，最后想整个产品怎么设计」的顺序，重新排列一下：

1. 有限身份：Make for Agent 的第一性问题不是界面，而是身份系统——非人执行体如何在组织里获得有限身份、有限权限和有限责任。没有独立身份，就没有细粒度权限；没有细粒度权限，就没有清晰责任。

2. 责任型通信：Agent 不需要社交型 IM，但需要可追责的通信；用户不一定参与通信，但在关键时刻必须能看见通信。通信的可见性是一个可调节的产品层，不是开关。

3. 责任容器优先：判断一个场景是否适合 Agent，先看它有没有足够好的责任容器。没有就别硬上——不是技术问题，是责任归属问题。

4. 关键断点介入：Human-in-the-loop 不应该是「人在流程里」，而应该是「人在责任链的关键断点上」。控制感要做成可调节的产品层，不同角色、不同任务需要不同粒度。

5. 上下文基础设施：让 Agent 进入生产，不是喂更多数据，而是建立 data / knowledge / identity 三层 context 的结构化与可治理。

6. 责任链定位：产品设计不能只问「Agent 的界面是什么」，要问「Agent 在责任链里的位置是什么」——它代表谁行动，权限来自谁，出错时谁买单。

7. 双面设计：面向人要满足控制感，面向 Agent 要满足经济性和主体性。同一个产品要同时处理两种需求，这是 Make for Agent 和传统产品设计最根本的区别。

Make for Agent，核心其实是 Make for Responsibility。不是因为 Agent 会成为新的用户，所以我们要为它设计产品。而是因为 Agent 让产品里的目标、权限、上下文、行动和后果第一次被系统性拆开了。过去由「用户」这个词含糊包住的一整套责任，现在必须重新显影。产品的用户也许会变。但更重要的是：产品终于不能再逃避责任链设计了。

转载原创文章请添加微信：founderparker