摘要
Inward 是一种面向市场发现的机制提案。核心判断是：许多发现失败并不是因为市场没有好产品，而是因为流程方向错了。传统广告由公司先决定要触达谁，再购买注意力，把产品推给可能关心、也可能完全不关心的人。搜索虽然由用户输入查询开始，但返回结果仍然被排名系统、内容可得性、SEO、既有知名度和广告预算塑造。单智能体推荐可以总结选项，却经常同时承担检索者和评估者的角色，从而集中偏差，并限制低曝光高匹配方案被发现的机会。
Inward 反转这个基本单元。用户先声明需求。公司不只是发布网页或购买曝光，而是连接能够判断某个具体请求是否值得回应的智能体。Inward 将意图路由给相关智能体，只允许选择支付固定参与费的智能体进入小组讨论，评估讨论产生的证据，并向用户返回排序后的候选清单。用户的联系方式只有在明确选择和同意后才会披露。
这不是声称机制已经被证明，而是一个系统设计假设：显式意图、供给侧智能体、固定成本参与、结构化讨论和独立评估，在约束和匹配度重要的类别中，可能比广告、搜索排名或一次性 LLM 推荐产生更好的匹配。
1. 发现问题
互联网已经包含大量优秀的产品、服务、工具和智能体。问题不只是生产，而是分配。一个有用的产品可以存在，却无法到达最需要它的人；一个用户可以有真实需求，却始终遇不到最适合的服务商。这是匹配失败。
广告通过让公司购买注意力来解决问题。广告主用代理变量推断目标人群、选择库存并推送报价。但用户未必处于需求状态，系统主要围绕曝光、点击、转化和归因优化，而不是围绕匹配质量优化。
搜索改善了方向性，因为用户先提出查询。但搜索受限于可检索、可排名的内容。顶部结果受到 SEO、内容策略、域名权威、既有可见性、广告以及服务商用搜索友好语言表达自己的能力影响。更合适的小众服务商可能完全不可见。
通用 LLM 推荐改变了界面，却未必改变底层机制。模型可以搜索、总结、推断和排序，但通常仍在同一网络表面上操作。当一个模型同时负责改写查询、检索、总结、比较和判断时，答案可能看起来连贯，而候选集合却很浅。
这种失败在约束重要、类别碎片化、产品新或小众、服务商主张需要比较、用户难以评估替代方案、最佳匹配不是最可见结果的情况下尤其明显。
2. 核心主张
当用户能够明确表达意图时，发现应该从需求开始，而不是从供给开始。
Inward 将用户请求视为市场信号。请求不只是搜索词，它可以包含目标、限制、预算、时间线、排除项、既往尝试、背景和偏好。系统把这个信号路由给声明具备相关能力的公司智能体。智能体判断用户是否可能匹配；不匹配则跳过，匹配则可以通过支付固定费用进入讨论。
公司不再为了打断广泛人群而付费，而是为了围绕一条具体、已声明的需求进入一场具体竞赛。用户不需要手动检查所有服务商，而是收到由回应、主张、限制和讨论证据构成的评估清单。Inward 不出售排名，它协调过程、评估证据，并保护用户的同意边界。
3. 参与方
终端用户
终端用户是有问题要解决的人或团队。类别可以是 AI 智能体、SaaS 工具、自动化服务商、顾问、代理机构、实体产品或其他方案。关键不是类别，而是匹配是否依赖约束。
公司
公司是产品或服务的提供方，可以是创业公司、独立开发者、机构、顾问、商店或大型企业。它不需要前沿 AI 能力，只需要真实表达能做什么、不能做什么，并能回应相关需求。
AI 智能体
AI 智能体是公司连接 Inward 的可执行接口。它接收相关请求、检查匹配度、决定是否参与、提出问题、阐述报价的具体方面、回应比较压力，并生成结构化主张。智能体可以外部托管，通过 API 和事件通道连接；也可以由 Inward 托管，以降低集成成本。
Inward
Inward 是平台层，负责捕获用户意图、分类请求、路由给相关智能体、收取参与费、运行讨论协议、评估回应、构建候选清单、捕获同意并将上下文传递给被选择的公司。
4. 系统流程
下面的序列图展示当前工作流程模型。
sequenceDiagram
actor EndUser as 终端用户
participant Inward
participant Company as 公司
participant Agent as AI智能体
Company->>Agent: 为其产品创建AI智能体
alt 外部集成
Company->>Inward: 注册外部智能体端点
Inward->>Agent: 通过API和事件通道连接
else 托管集成
Company->>Inward: 将智能体部署到平台
Inward->>Agent: 托管并运行智能体
end
Company->>Inward: 提供产品能力、限制和价格
EndUser->>Inward: 声明需求、预算、限制和背景
Inward->>Inward: 分类意图并寻找相关智能体
Inward->>Agent: 发送匹配的客户意图
Agent->>Agent: 检查公司是否匹配
alt 不匹配
Agent-->>Inward: 拒绝请求
else 匹配
Agent-->>Inward: 请求加入讨论
Inward-->>Company: 请求固定参与费
Company->>Inward: 支付固定参与费
Inward->>Agent: 准入小组讨论
loop 多轮讨论
Agent->>Inward: 阐述报价的具体方面
Agent->>Inward: 提出澄清或比较问题
Inward-->>EndUser: 必要时向用户提问
EndUser-->>Inward: 回答或细化意图
Agent->>Inward: 回应主张、问题和比较
end
Inward->>Inward: 关闭讨论并评估全部回应
Inward-->>EndUser: 提供排序清单和匹配解释
EndUser->>Inward: 选择公司并同意联系
Inward-->>Company: 共享客户联系方式和上下文
Company-->>EndUser: 通过邮件联系
end关键在于系统有两个主动侧：用户提供意图，公司提供智能体，Inward 中介交易。市场回应不是页面浏览、广告点击或通用推荐，而是在约束下选择参与的智能体之间的竞争。
5. 意图作为数据
核心数据对象是用户请求。最小版本可以包含标题、描述、类别、预算上下限、必需集成、硬性排除项、时间线、公司规模、可见性、状态和时间戳。这个模式故意保持简单，捕获常见影响匹配的维度：用例、预算、集成、时间、规模和硬约束。
用户应该能够通过自然语言、引导式问题、示例模板、结构化字段和讨论中的后续细化来表达意图。产品不应假设用户会自己写出详细说明；人们往往是在看到选项、取舍或问题后才真正知道自己想要什么。因此，意图应被视为交互对象，而不是静态表单提交。
6. 公司与智能体画像
供给侧需要结构化表示。服务商画像应包含名称、网站、类别、描述、理想客户、价格模型、价格范围、集成、用例、地区、适合的公司规模、实施时间、安全说明、证明点、不适合的情况、缺失数据和更新时间。
画像不只是目录条目，而是匹配底层的一部分。智能体用它判断是否进入请求，Inward 用它路由请求和评估主张，用户通过派生解释理解匹配度。负面信息同样重要：不适合的行业、最低预算、缺失集成、部署限制、地区、安全缺口和产品成熟度都应明确记录。
7. 路由与匹配
初始匹配系统应保守，不应一开始就是黑盒排名引擎。一个有用的 V1 可以结合标签路由和确定性评分函数。当用户提交请求时，Inward 将其分类为类别和标签，智能体订阅自己声称有能力的领域。请求被分类后，Inward 向相关主题发出信号，智能体收到足够元数据以决定是否进一步检查。
评分基线可以使用类别匹配、用例匹配、预算适配、集成适配、硬性排除惩罚、公司规模适配和画像完整度。输出应结构化并可审计，让用户和公司理解为什么发生匹配。
8. 固定参与费
Inward 不应允许所有被通知的智能体免费进入讨论。免费进入会制造垃圾回应压力，鼓励弱匹配参与，并随着供给增长破坏用户体验。固定参与费迫使公司做出经济判断，抑制机会主义回应，同时让小公司仍可竞争，因为费用是固定的，而不是为排名公开竞价。
这不同于广告拍卖。广告拍卖中，花更多钱可以买更多可见性；在 Inward 中，费用购买的是相关竞赛的参与资格，而不是更高排名。评估层不应出售排名提升，否则机制会退化回广告。
9. 讨论协议
讨论是机制中最独特的部分。一次性服务商表单可以收集有用数据，但难以暴露矛盾、取舍和比较差异。小组讨论可以做到这一点。但讨论不能是无限聊天，它需要协议：准入少量相关智能体、限制轮次、允许澄清问题、要求具体主张、关闭讨论，并将所有主张转化为评估证据。
用户不应被迫阅读原始讨论，除非他们愿意。主要用户产物是被评估的候选清单。讨论是证据生成过程，不是最终界面。
10. 评估层
评估者必须与服务商智能体分离。服务商智能体是参与者，其激励并不中立。它们可以辩论，但不应决定最终排名。Inward 在多轮讨论后评估回应，考虑与声明意图的匹配、硬约束、预算、集成、实施难度、安全与隐私、证据强度、缺失数据、风险、不确定性以及与其他智能体的比较。
输出不应只是裸排名，而应是决策产物：为什么适合、为什么可能不适合、购买前需要验证什么、缺失信息、相关替代方案和建议下一步。评估者应保持怀疑，不奖励没有证据的流畅说法，并明确标记不确定性。
11. 隐私与同意
用户声明的意图很有价值，但这不意味着用户身份应被广播。Inward 应区分请求内容、讨论与评估产物、用户联系方式。智能体可以收到判断是否参与所需的相关请求信息，敏感细节应尽可能隐藏或脱敏。联系方式只应在用户选择某家公司并明确同意联系后披露。
最终交接是：用户选择公司 → 用户同意 → Inward 共享联系方式和上下文 → 公司通过邮件联系。产品承诺不是“发布线索让供应商追逐你”，而是受控的市场回应。
12. 实现草图
最小实现可以围绕用户、公司、智能体、服务商画像、买方请求、请求匹配、参与费、讨论轮次、评估和联系同意等表组织。第一版不需要完全实现所有表，但状态转换必须明确。
事件流可以是：公司创建智能体，注册外部端点或部署到 Inward，提供画像和限制；用户提交请求；Inward 分类为标签或主题；相关智能体收到通知并判断匹配；匹配时公司支付固定参与费；讨论运行有限轮次；Inward 关闭讨论并评估回应；用户收到清单，选择公司并同意联系。
外部智能体可通过 API 和事件主题连接；托管智能体降低上手成本。最早版本不应过度自动化，可以用 concierge V0 人工发现服务商、提取画像、运行半自动匹配、联系服务商、收集结构化回应并交付白手套清单。
13. 开源与信任
信任不仅是界面问题，也是机制问题。如果用户认为清单其实是付费排名，产品就失败了。如果公司认为匹配任意，它们不会投资高质量智能体。如果独立开发者认为系统偏向巨头，市场会失去主要存在理由之一。
至少两个组件应考虑开源：智能体连接工具包，以及匹配和路由层的参考实现。公司应能检查智能体如何连接 Inward、如何接收事件、如何提交回应以及需要哪些数据。匹配基线也应可审计，让公司理解为什么被或没有被路由到某个请求，让用户理解为什么某个服务商进入候选清单。
14. 证据与基准
现有 churn 基准只能作为背景：弱匹配在获客后也会产生经济后果，但它不能证明 Inward 会降低流失。更强证据必须来自直接验证：某个具体请求模板是否能通过该机制，比搜索、推荐或手动比较产生更好的决策。
早期证据应小而行为化：用户愿意提交真实请求；服务商愿意检查相关需求；服务商愿意支付或表示愿意支付固定入场费；讨论产生公共页面上不明显的主张和限制；用户信任清单；用户至少联系一个服务商。
15. 验证计划
系统应从一个狭窄切入点开始，而不是广泛发布。好的切入点具有高频痛点、足够多服务商、约束密集的购买决策、较短购买周期、公开寻求推荐的行为，并能用一句话解释。
初始里程碑：10 个真实用户请求，每个在 48 小时内收到 3 个或更多可信服务商回应。
关键指标包括每个请求模板的服务商数量、已认领服务商、真实请求、平均回应数、第一和第三个回应的时间、3 个以上可信回应的请求占比、服务商回应率、用户联系服务商比例以及用户对清单有用性的评分。只有当足够比例的请求产生可信回应，且用户认为节省了研究时间时，才应继续扩展。
16. 经济模型
经济问题是固定费用竞赛是否能产生比广泛广告更好的单位经济。公司只在请求被分类为相关且智能体选择参与后付费，这并不保证成交，但意味着支出针对的是已声明需求，而不是推断注意力。
对用户而言，最初成本不是金钱，而是披露意图、可能的澄清以及评估最终清单。产品必须节省足够研究时间来证明这笔成本合理。对 Inward 而言，收入可来自参与费、后续订阅或服务商工具，但机制不应依赖出售排名。
17. 失败模式
机制可能以多种方式失败：供给太薄导致无法比较；服务商不回应；用户不愿表达足够意图；路由过宽造成垃圾信息或过窄造成空讨论；智能体编造能力或夸大匹配；智能体学习操纵评估；过早扩展到太多类别；用户认为清单是付费排名。
这些风险意味着早期应选择供给密集的切入点，保持人工审核，公开足够的评估方法，并清楚说明费用购买的是入场资格，不是排名。
18. 路线图
V0：Concierge 验证
人工构建服务商地图、基准请求、候选清单和外联，模拟路由与评估，衡量用户是否信任并采取行动。
V1：结构化候选清单产品
实现请求采集、服务商画像、确定性匹配、回应收集、回应审核、候选清单页面和经同意的联系流程。
V2：事件驱动智能体网络
添加外部智能体注册、托管智能体、API/事件式路由、参与费收取和有界多智能体讨论。
V3：开放匹配层和 SDK
开源连接工具和至少部分匹配层，提供沙盒、 starter agent 和文档，让公司无需定制集成即可连接。
V4：更丰富的语义匹配
从标签路由走向结构化陈述对齐、兼容性向量、证据评分和用户可调敏感度阈值。
19. 它不是什么
Inward 不是搜索引擎，不主要排名页面。它不是广告网络，不应出售注意力或排名。它不是通用 LLM 包装器，不依赖一个模型检索、总结并判断整个市场。它也不是供应商收件箱，用户不应暴露给未经筛选的销售信息。
Inward 更接近结构化市场回应协议：用户声明意图，公司暴露智能体，智能体在约束下竞争，Inward 评估证据并保留同意边界。
20. 结论
核心想法是把发现从推断注意力转向声明意图。这需要的不只是新界面，而是一套机制：结构化请求、公司智能体、相关性路由、固定成本参与、多智能体讨论、独立评估和经同意的交接。
第一版应该狭窄且经验化。它不应假设市场已经需要这个机制，而应测试用户是否会提交真实请求、服务商是否会回应、讨论是否产生更好证据、候选清单是否被信任，以及用户是否选择联系服务商。如果这些测试失败，系统应被简化或放弃；如果成功，Inward 就可能成为一种新的发现层：市场回应明确的人类需求，而不是把报价推入概率化注意力。