独行录 / opcmenu MCP Server

【需要登录】创建一个持久的独行录合作目标；用户成为发起人。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 先 get_my_work 核对已有目标，再创建；返回 id 用于 get_collaboration_goal/create_collaboration_task。

【需要登录】在独行录目标中创建任务；assigneeId 省略为自己，指定他人必须是目标合作人，会通知对方。用户授权派给该人后才调用。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 创建前后用 get_collaboration_goal 核对。

【需要登录】看独行录目标详情、我的权限、合作人、任务。服务校验成员权限；includeClosed=true 包含已了结任务，最多 200 条，reachingLimit 表示可能截断。读任务会幂等补周期期次。创建任务用 create_collaboration_task，发起人改目标用 update_collaboration_goal。

【需要登录】按 assigned_to_me（待我做）或 assigned_by_me（我派给他人）列独行录任务；done=true 查看已了结记录，goalId 缩小到某目标。归档目标不在此列表，归档目标任务用 get_collaboration_goal。任务查询会幂等补周期期次。reachingLimit=true 表示可能截断，不代表总数。

【需要登录】被指派人可设 TODO/DOING/DONE/DECLINED；只有指派人可设 CANCELLED。DONE/DECLINED 的 note 会作为完成留言/婉拒理由并通知指派人。不能代替他人宣称工作已完成。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 list_collaboration_tasks(done=true) 或 get_collaboration_goal(includeClosed=true) 核对。

【需要登录】发起人更新目标标题、意图、截止或状态 ACTIVE/COMPLETED/ARCHIVED。归档后目标不再出现在默认待办。省略保留，intent/dueAt=null 清空。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_collaboration_goal 核对。

【需要登录】更新任务标题、描述、截止；换被指派人需要指派权限且可能通知新负责人。权限由服务校验，省略保留，detail/dueAt=null 清空。状态用 set_collaboration_task_status。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_collaboration_goal 核对任务。

【需要登录】新建一个产品 / 作品，先过后审：创建后立即发布对外可见。slug 可选：不填由服务端按名称自动生成；被占用会自动改派生地址。创建后可用 update_my_product 继续补充链接 / 媒体 / 标签。

按 id 或 slug 获取产品完整详情（owner 主理人 / 描述 / 链接 / 媒体 / 分类 / 标签 / 发布时间）。两个参数二选一，slug 优先。 【何时用】用户点了某个产品想看详情，或 search/list 返回后要展开看某条。 【相关 resource】也可以用 resources/read URI: opcmenu://product/{slug}。

只取某产品的星级汇总（平均分 + 分布 + 总数），不拉评价列表——省 token 的「评分多少」快查。要看评价文字用 get_product_ratings。

返回某产品的口碑：星级汇总（平均分 + 1~5 星分布 + 总数）+ 评价列表（文字 + 星级）。登录时附带 myRating。get_product 详情不含评价，要口碑必须调本工具。 【口径】站内口碑刚起步，**绝大多数产品是 0 条评价——空返回是常态，不是查询失败**。别因为查空就换别的工具反复试，更别去站外找评价冒充站内口碑。 【写】rate_product 打分写评。

【需要登录】把我的产品在「已发布 ⇄ 已下架」之间切换（仅这两个状态互切，其余状态由系统管理）。先用 get_my_products 拿 productId 和当前 status。

【需要登录】更新当前用户名下某个产品（仅本人可改）。先用 get_my_products 拿 productId。所有字段可选，只传想改的；links 传则整组替换。 【发布】先过后审：立即生效，后台异步做风控审计，不卡审核。**注意：编辑会把已下架（ARCHIVED）产品重新发布上架**——只想改内容不想上架的，改完再用 set_product_status 下架回去。

【何时用】用户对某一场感兴趣、或准备报名之前调它。**一次调用给全上下文**：公开详情（简介/时间/地点/名额/题目表/答疑群）＋（登录时）我的报名状态、每题的现值、还缺哪几个必填项——App 上这是两个接口两屏，agent 端合成一次。 【组合链】① viewer.missingRequired 非空 → 照 fields 里的 label/hint/options 问用户，答完直接 submit_signup(slug, answers=[…])；② 缺的题在别的场次也要填 → get_signup_gaps 一次问完；③ 已经 submitted=true → 用 list_my_signups 看主办方处置到哪一步了，别重复报。 【口径/坑】① fields[].fillable=false 的题（基本都是 type=file 的附件题，如商业计划书）**agent 通道传不了文件**，只能让用户去 App / 报名页传——绝不许瞎编「已填」或塞一个链接冒充。② 本工具**不返回** autofillScript（那是注入 webview 的几 KB JS，对 agent 零价值）。③ fields[].valuePreview 里，联系方式/证件类的题一律打码——那是给你判断「填没填」的，不是拿来复述给用户听的。④ signup.externalIsCanonical=true 表示正式报名在主办方的外部表单上，站内提交只是留资＋代填。⑤ requiresPhoneVerification=true 只约束**公开报名页上的游客**（没登录填表要短信验证码）；你带着密钥就是已登录用户，submit_signup 不需要验码，别拿这个字段去劝退用户。⑥ signup.canOneClick=false 且没有 externalUrl 时这场的报名还没配好，submit_signup 会直接拒（error=signup_not_open），别硬报。

【需要登录】【何时用】用户想一口气报好几场（或问「我现在能报的都缺什么」）时调它。**这是 agent 独有、App 永远不会有的接口**：一次算完多场的缺口，并把同一个题目跨场去重合并——「姓名、微信、一句话项目介绍」问一遍就够，不用一场问一遍。 【组合链】① 不传 slugs 就自动取 list_signup_feed 前 N 场**我还没报的**；② 拿 missingCombined 一轮问完用户；③ 通用项 update_my_signup_profile 一次落库；④ 逐场 submit_signup（这时基本零缺口）。想看某一场的完整题面再 get_signup_activity。 【口径/坑】① missingCombined 里每项带 activities=[这几场都要]，问一次可以覆盖多场——**别自己在上下文里做集合运算**，那既费 token 又容易漏。② fillable=false 的项是附件题，agent 传不了，只能提示用户去报名页/App 传。③ 已报过的场次（submitted=true）默认不进结果，除非显式点名在 slugs 里。④ 一次最多 10 场，服务端分批取，别指望它当全站扫描器用。

【需要登录】【何时用】用户明确说「我要联系这个人 / 把他的微信给我 / 他报名时写了什么」时才调。**这里才解密联系方式**（微信/邮箱/手机），list_signup_submissions 默认是不给的。 【组合链】list_signup_submissions(slug, q=…) 定位到某一行 → 本工具取该行完整答案与联系方式 → review_signup_submission 单独处置他 → 想直接在站内找他聊就用 start_conversation（仅当他是站内注册用户，见返回的 user.id）。 【口径/坑】① 证件号（身份证等）**永远不解密**，返回的是打码值——那条只有站方 admin 的显式 reveal 能解且写审计。② 报名者账号上的手机号（他没在这场表单里填、而是注册手机号）会打码成尾 4 位：主办方没收集的东西，不该因为换了个接口就拿到明文。他在表单里亲手填的手机号照给。③ 拿到的联系方式是给用户去联系人的，**不要在对话里主动复述整串**，除非用户要求。④ submissionId 必须属于这场活动，否则 404。

【何时用】用户问「最近有什么能报名的 / 这周截止的有哪些 / 有没有黑客松」时调它。这是站内**唯一能真报名**的机会列表：每一场都挂着可用的报名表单。 【组合链】拿到 slug 后：① get_signup_activity(slug) 一次拿全「详情 + 我的报名状态 + 还缺哪几题」；② 缺项补齐后 submit_signup(slug) 直接报；③ 想一次盘几场就 get_signup_gaps(slugs=[…]) 拿跨场合并的待答清单，问一轮就够。 【口径/坑】① 本工具返回的每一条都**当场能在站内报**（判据是这场挂了报名配置，与 Activity.type 无关——平台自办/承办的赛事也是 type=COMPETITION，照样在这条 feed 里）。list_activities 是更宽的活动资讯面，其中导入的外部赛事只能去主办方官网报，两者别混。② feed 已按「置顶 → 截止近的优先（无截止排最后）」排好序，「这周截止的」直接按顺序截即可，**别自己重排**。③ 首屏返回的 kinds 是服务端算的**真实类目计数**，空类目根本不出现——照它渲染选项，别拿 SIGNUP_KINDS 全集当菜单。④ 登录时每条带 submitted=true/false，已报的别再问用户要不要报。⑤ startAtKnown=false 表示这场的开始时间是导入时兜底顶上的假值，**别对用户念那个日期**。

【需要登录】【何时用】主办方问「报了多少人 / 今天新增几个 / 有哪些做 AI 的报了」时调它。返回名单页 + 首页概览（总数 / 今日新增 / 待初审 / 渠道分布）。 【组合链·批量处置，这是 agent 对 web /pro 的碾压位】list_signup_submissions(slug, q='Agent') 拿到 items[].id → bulk_review_signup_submissions(slug, ids=[…], reviewStatus='SHORTLISTED', preview=true) 先让用户过目 → 确认后 preview=false 落库 → 剩下的人 reviewStatus='WAITLIST' 再来一次。在 web /pro 上这是勾 200 个复选框。要联系某个具体的人再用 get_signup_submission(该行 id) 单独取联系方式；要整份表格用 issue_signup_export_link。 【口径/坑】① **默认不返回答案全文**：只给每行答了哪几题的 key 列表 + 昵称。要看某几题的内容用 fields=['project_intro'] 点名投影。② **默认不返回联系方式**（手机号/微信/邮箱一律裁掉或打码），只告诉你 hasContacts / contactKinds；确实要联系人再传 includeContacts=true，或对单个人用 get_signup_submission。证件号任何时候都不解密。③ 投影出来的答案里，夹带在自由文本中的手机号/邮箱同样会被清洗掉——那是刻意的，不是数据坏了。④ limit 默认 20、上限 50（服务层能给 100，这里刻意收窄：一屏 100 行报名答案灌进上下文没有意义）。⑤ q 是跨三处搜的（匿名单字段 / 报名者账号昵称手机 / 答案全文），搜项目名和公司名最好用。⑥ status（投递态）与 reviewStatus（录不录）严格分离，别混着筛。⑦ overview 只在第一页（不带 cursor）返回。

【需要登录】【何时用】用户随口给了一条以后每场报名都要用的信息（「我微信是 xxx」「团队 3 个人」「所在城市杭州」），先落进跨表单复用的**报名资料覆盖层**，下次报任何一场都会自动带出来。 【组合链】get_signup_gaps 拿到 missingCombined（跨场去重后的待答清单）→ 问用户 → 本工具一次性写进覆盖层 → 之后每场 submit_signup 都不用再问。key 必须用 get_signup_activity / get_signup_gaps 返回的那个 key（跨活动稳定，别自造）。 【口径/坑】① 这里**只写报名场景的覆盖层**，绝不改主页/公司/产品本体——改那些走 update_my_profile。② 只收文本；文件类答案（BP 等）只能走 App 的上传通道，这里写进去会把已传文件的记录顶成一串文本。③ 敏感题（证件号）刻意不做跨表单记忆，别往这儿写。④ 写入的值不会回显在返回体里（只回 key），这是刻意的隐私收口。

【需要登录】以当前用户身份发布一条需求（需求互换核心 loop 的起点）。先过后审：发布即展示在需求信息流，后台异步风控，不用等审核。发布后系统自动做向量撮合、推送给最匹配的主理人；也可以随后用 get_need_recommendations 主动看谁能满足。 【写好它】title 认真写清楚要什么（3–120 字）；detail 越具体，撮合和搜索越准。示例：「找人合作把我的效率工具做出海版本」「找能提供小程序代开发的主理人」。发布是公开动作：发布前把拟发的 title / detail 给用户过目确认。 【挂载】contextType+contextId 可把需求挂到自己的产品/活动/某人（成对传）。配图先用 upload_image_from_url 拿稳定 URL。

【需要登录】硬删除自己的需求（连同全部接洽记录，不可恢复）。日常收尾优先用 cancel_need（保留记录）或 unpublish_need（可逆下架），删除只用于确实要抹掉时——调用前先向用户确认。 【失败语义】非本人 403 not_your_need。

按 id 查单条需求的完整卡片：类型 / 标题 / 详情 / 配图 / 状态 / 作者（含 canOffer 与代表产品）。登录时附带 isMine 与 displaying。查不到返回 found=false。 【口径】接洽不限人数（没有名额概念），也没有报酬/感谢费。displaying=false 表示作者手动下架了（status 仍是 OPEN——下架只改展示期不改状态），别再向用户推荐它。 【相关 resource】opcmenu://need/{id} 【后续】想接这条需求 → contact_need（需登录），它返回 conversationId 可以直接接 send_message。

【需要登录】对**自己发布的**某条需求拉个性化推荐：谁最可能满足它（一人一卡，按「对方能提供的 ↔ 我的需求」向量匹配 + 回复率/活跃度加权，含 matchScore / matchReason / authorNeeds）。这是「发完需求主动出击」的工具，不用干等撮合推送。 【组合链】看中某人 → contact_need 对方的需求或 start_conversation 直接开聊。续拉传回 nextCursor，并把已看过的需求 id 放进 seen 软性下沉。 【越权】只能查自己的需求，别人的会被拒（not_your_need）。

【需要登录】编辑自己发布的需求（仅 OPEN 状态可改）。可改 类型 / 标题 / 详情 / 配图，只传想改的。先用 list_my_needs 拿 needId。 【失败语义】非本人 403 not_your_need；非 OPEN（已取消或历史遗留关单）409 need_closed。被接洽/被承接不改变需求状态，仍是 OPEN、仍可编辑。

【需要登录】为当前用户创建一人公司主页（每个用户最多一家；已存在则等价于更新）。slug 全局唯一（被别人占用会报 slug_taken）。 【发布】先过后审：立即生效，后台异步风控审计。 【提示】description 越详细，主页内容质量越高。建到了就可以在引导里 complete_onboarding。

按 slug 获取某个一人公司主页（公开视角：仅返回已发布 PUBLISHED 的公司；本人 owner 可见自己任意状态的公司）。查不到返回 found=false。 【何时用】用户想看某家一人公司在做什么。 【相关 resource】opcmenu://company/{slug}

【需要登录】返回当前用户名下的一人公司主页（任意状态，含已归档 ARCHIVED；PENDING_REVIEW 仅历史遗留数据）。没建过则返回 company=null。 【何时用】改公司资料前先用它读现状拿到现有字段 / slug / 状态。每个用户最多一家公司。

【需要登录】更新当前用户名下的公司主页（按 ownerId upsert，所有字段可选但仍要满足 schema：传 slug/name 时格式校验）。先用 get_my_company 读现状。slug 被别人占用会报 slug_taken。 【发布】先过后审：立即生效，后台异步风控审计。

【需要登录】列出当前用户名下的产品（含待认领 / 已发布 / 已下架等全部状态，以及每个产品的全部链接）。 【何时用】agent 要改某个产品的链接/资料前先列出来拿 productId；或盘点「我发布了哪些东西」。

【何时用】用户想看「热门」「今日新品」「随机逛逛」「月度榜」时。比 search 更适合无明确意图的浏览。 【type 取值】 - hottest: 已认领主理人优先 + 累计浏览量排序 - today: 今日新发布 - random: 随机抽取（已认领优先，探索用） - leaderboard: 上月榜（上个自然月的预计算快照，与 hottest 的累计热度不是一回事）

按分类系统性地逛已发布产品（已认领主理人优先）。比 list_products 多了分类过滤，比 search_products 更适合「结构化浏览某一类」而非语义搜索。

【何时用】用户用自然语言找**产品/作品**时，比如「有没有给独立开发者用的财务工具」「记笔记的极简 app」「Notion 替代品」。返回按相关度排序的产品卡片，含 slug / tagline / 所属主理人。 【只管产品】找「人」（能提供某种价值的主理人）用 search_people；搜需求用 search_needs。 【机制】关键词 + 向量（阿里云百炼 text-embedding-v3）双路并行召回后 RRF 融合，另有 LLM 查询扩展 / 精排，各步可自动降级。结果里的 mode 一般为 hybrid。 【常见 pitfall】问 "什么是独行录"、"如何注册" 这种 meta 问题不要用本工具，那是站点介绍不在数据里。

【需要登录】给当前用户加一条链接（不动其它字段）。type 见 LINK_TYPES（website/github/wechat/douyin/shipinhao/email/phone…），visibility 缺省 public。 【例】「把我的抖音加上，设为好友可见」→ type=douyin, url=..., visibility=friends。

【需要登录】返回当前用户的完整资料：昵称 / 简介 / 介绍 / 所在地 / 全部链接（含 friends/private 等所有可见范围）/ 身份 persona。 【何时用】agent 要帮用户「把资料填到别的平台」「检查我留了哪些联系方式」「改我的链接」之前，先用它把现状读出来。比 get_creator 多了私有链接和 persona（get_creator 是公开视角，只吐 public）。

【需要登录】按 url（可加 type 进一步限定）删除当前用户的链接。匹配不到则 no-op。

【需要登录】更新当前用户资料，立即生效（资料修改不走审核）。所有字段可选，只传想改的；links 传则整组替换（要增删单条用 add_profile_link / remove_profile_link 更方便）。建议先 get_my_profile 读现状再改。 【canOffer 是全站撮合的轴心】search_people 搜的就是它、需求信息流的 matchScore 按它算、get_need_recommendations 拿它给作者推人。留空 = 从撮合池里掉出去，谁也搜不到你。帮用户入驻/整理资料时**一定要顺手把它写上**，而且要写具体（「能给早期项目做 0→1 的小程序开发，两周内出可用版本」远胜「技术合作」）。

【需要登录】检查当前用户是否满足发起活动的前置条件。**两条轨，满足任一即可**：轨 A 主理人 —— 资料完善（bio + intro≥10 字）且至少 1 个已发布产品；轨 B 主办方 —— 入驻已完成 + 主办方资料四项齐全（主办方名称 / 联系人姓名 / 联系电话 / 一句话介绍）。ok=true 时 via 说明走的是哪条（owner=轨 A，organizer=轨 B）。 【ok=false 的 reason】profile_incomplete = 入驻还没走完（入驻本身就会强制填 bio/intro，所以这条等于「先去完成入驻」）；organizer_profile_required = 入驻完了但缺主办方资料四项——这是实际最常见的一条，只差一个已发布产品的轨 A 用户也会落到这里（对正要发活动的人来说，填四项资料比再发布一个产品近）；no_published_product = 老枚举，现口径下基本不会返回。 【怎么补】想走轨 A 就用 create_product 发布产品。缺主办方资料**这里没有对应的写工具**，别拿别的工具去试——那四项要走 POST /v1/me/organizer-profile，联系电话必须过短信验证码，agent 端做不了；请引导用户去 App 或网页版填「主办方资料」（四项一次填完，不拆步、不跳过）。 发起活动（create_organizer_activity）前先用它，免得白填。

按 id 或 slug 拿活动详情：标题 / 描述 / 时间地点 / organizer / 报名情况。两个参数二选一，slug 优先。 【怎么报名——判据只看 signup，不看 type】 - **signup 不为空 → 站内能报**：用 get_signup_activity 看要填什么、submit_signup 提交。**站内报名只有这一条链。**（平台自办/承办的赛事也常是 type=COMPETITION，一样在站内报——别拿 type 判。） - **signup 为空且 externalUrl 非空** → 这是导入的外部赛事资讯，站内报不了，如实让用户去 externalUrl 那儿报。 - 两个都空 → 这场就是没开报名，别编一个入口出来。 【相关 resource】opcmenu://activity/{slug}

【需要登录】改我办的活动的**本体信息**（先过后审：立即生效；slug/type 不可改）。先用 list_my_activities 拿 activityId。 【分工——别调错】活动本体（标题/介绍/时间/地点/长图/封面）走这里；**报名表单与报名方式**走 update_organizer_signup_config。 【红线：截止时间只能往后不能往前】把 registrationDeadline 改早，会把正在填的人当场挡在门外，且已开始填的草稿全部作废。用户要「提前截止」时先跟他确认清楚这一点。

【需要登录】【何时用】「我在产业链的什么位置」「我的上游下游是谁」「这家公司的上下游有哪些」。返回以某个节点为锚的自我中心视图：上游若干环 + 锚点自己的链位 + 下游若干环，每环带成员。 【组合链·多跳】 · **不传 subjectType/subjectId 就直接落在「我」身上**（我 + 我的已发布产品里的默认锚点），一次调用就位；返回体里带 myAnchors 告诉你我还有哪些锚点可切。 · 拿链上**任意成员的 id 再调本接口**就是下一跳（「上游的上游」）——这就是递归展开产业链的全部方法。 · 先 metadataOnly=true 探方向（只出类别和计数，不判成员，快且省），锁定要看的那一类再用 list_chain_group_members 翻它的成员。 · 成员 members[].id（type=user）→ get_creator → start_conversation；members[].claimed===false 表示这条是爬虫抓来的目录条目，**背后没有能对话的真人**，别去开聊，引导用户看 siteUrl。 · 我自己还没归位（anchor.placed=false）→ set_my_chain_position 用一段自由文本归位。 【口径/坑】 · **这个接口真花钱**：成员是 LLM 成对审核判出来的（判完落缓存）。**别为了看全而循环翻到底，一屏够用**；也别对同一个锚点反复调。 · memberLimit 不对外开放任意数值（照 apps/api chain/anchor 路由的约束），只给 metadataOnly 一个开关：true = 一个成员都不判，只要类别元数据。 · warming=true 表示还有候选没判完、后台在续判——这时候**空成员不等于没人**，如实说「还没判完，等会儿再看」，不许下「这一环没人」的结论。 · 每组的 supply 字段区分三种空：none（站内确实还没有这类主体）/ gated（有候选但证明不了真实价值流，宁缺毋滥）/ warming（还在判）。三种说法完全不同，别混成一句「没有」。 · profileVersion 是分页游标的绑定版本，翻成员时要原样带上（见 list_chain_group_members）。

【需要登录】【何时用】get_chain_anchor 某一类只给了一屏预览，用户想再看几个时。按 groupId 单独翻那一组。 【组合链】get_chain_anchor 拿 groupId + direction → 本工具翻页 → items[].id 再喂回 get_chain_anchor 就是下一跳；items[].id（type=user）→ get_creator → start_conversation。 【口径/坑】 · **游标是 HMAC 签名的、且绑定 profileVersion**：nextCursor 必须**原样透传**，改一个字符就 400 invalid_cursor。 · 撞 409 chain_cursor_stale = 锚点画像在你翻页期间变了（他改了资料/产品）。**别拿同一个游标重试**，重新调 get_chain_anchor 从第一页来。 · 同样**真花钱**（每翻一页都是一批 LLM 成对审核），同样别循环翻到底。 · warming=true / supply=warming 时空批只代表「还没判完」；supply=gated 是「判过了，没有一个能证明存在真实价值流」；supply=none 才是「站内确实没有这类主体」。 · pageInfo.total 经常是 null（不穷举 LLM 判定就得不到精确总数）——**null 就说不知道，绝不拿当前页长度冒充总量**。

【需要登录】【何时用】**全平台唯一一个「自由文本即写入」的接口，正是 agent 的主场。** 用户在对话里刚说完自己在干什么，你把那段话整理成一句 describe 直接提交，LLM 据此推出链位并把他并进链网。App 里这一步要用户自己打开定位页、切到产业链、想一段话再打字。 【组合链】提交成功 → get_chain_anchor 立刻能看到他新的上下游环 → 从环里挑人 get_creator → start_conversation。不传 subjectType/subjectId 就是给「我」归位；给产品归位就传 subjectType=product + 产品 id（必须是我自己的产品，先 get_my_products 拿 id）。 【怎么写 describe】把用户原话整理成「给谁做什么、用什么做、做完交付什么」，5~500 字。**别替他编**——他没说的上下游不许你加。 【口径/坑】 · 归位记 source='declared'：用户拍板的链位钉死，后续系统自动重推**不会覆盖**它（画像的其它字段照常刷新）。 · 失败分支返回体自带出口，照着念：position_unclear（看不出你在干什么，要补「给谁做什么」，**别重试**）/ position_relations_unclear（看得出做什么、看不出上下游是谁，要追问「活儿从谁手上接、做完交给谁用」，**别重试**）/ chain_source_changed（你刚改过资料或产品，原样重提一次即可）/ llm_unavailable（判链位的模型不在，过几分钟再试，别说成描述有问题）。 · 这是一次完整的 LLM 重推，**慢且花钱**。同一段描述重复提交会被本工具去重（返回 deduped=true），别靠重复调来「催」。 · 归位会改变他在别人产业链视图里的位置——这是对外可见的写操作，不是本地设置。

【需要登录】列出当前用户发布的需求（现行状态只有 OPEN / CANCELLED；IN_PROGRESS / COMPLETED / EXPIRED 仅历史遗留数据——完成态记在每条承接（claim）上，需求不因某条承接完成而关单），时间倒序、游标分页。编辑 / 下架 / 取消 / 拉推荐之前先用它拿 needId；查某条承接是否完成用 get_conversation_needs 看 claim 状态，别按 status=COMPLETED 过滤。信息流里不会出现自己的需求，盘点自己的一律走这里。 【下架 ≠ 改状态】手动下架只把需求移出信息流，status 仍是 OPEN——**判据是每条返回里的 displaying 布尔**（服务端按服务器时钟算好的），别拿 status 猜。只想看还在展示的传 displaying=true。

【何时用】用户想看「大家都在找什么」「有什么我能帮上/接得住的需求」时——这是需求互换的主入口。 【结构】一人一卡按作者聚合：每张卡是一位主理人（主打 author.canOffer「能提供什么」+ 代表产品），主需求平铺在卡上，authorNeeds 列出该作者在架需求（最多 6 条，主卡需求在首位）。登录后按「TA 的需求 ↔ 我的价值」轻个性化排序并附 matchScore/matchReason；匿名同管线纯先验排序。 【组合链】看中某人 → contact_need 该需求拿 conversationId → send_message 直接开聊。定向找用 search_needs / search_people。想让匹配更准就先补自己的 canOffer（update_my_profile）——排序就是拿它跟对方需求比的。 【口径】接洽不限人数，没有「名额」这回事，也没有报酬/感谢费——看到谁在找就直接聊。 【分页】cursor 原样回传延续同一副牌；不传 = 重新洗牌。

【何时用】用户想定向找「有没有人在找 X」时——「有没有人想找设计合作」「谁在找出海经验交流」。比 list_needs_feed（推荐流）更适合带明确关键词的检索。 【机制】标题/详情关键词 + need_embedding 向量混合检索（RRF 融合），只出在架需求（与信息流可见性口径一致）。返回完整需求卡（含作者 canOffer）。 【组合链】命中 → get_need 看详情 → contact_need 接洽拿 conversationId → send_message 开聊。

【需要登录】【何时用】用户说「帮我发一场分享会 / 建一个报名」时调它。这是站内建活动的**唯一正确入口**：活动本体 + 报名配置一次写入，建完立刻进报名 feed、报名页立刻可用（先过后审，不留灰度闸）。 【组合链】建完拿 slug → signupPageUrl 直接发给用户去转发 → get_organizer_activity(slug) 读现值 → update_organizer_signup_config(slug) 改题目/联系方式 → 报名进来后 list_signup_submissions(slug) 看名单 → bulk_review_signup_submissions 批量处置 → issue_signup_export_link 导出。活动本体（标题/时间/地点/截止/名额）改动走 update_activity。 【口径/坑】① **别逐字段构造几十题的表单**：不传 extraQuestions 就落系统基线四项（姓名/手机号/微信号/一句话项目介绍，全是跨活动复用的稳定 key，报名者一键带出）；额外题只要一行一个中文题面丢进 extraQuestions，key/type 由服务端生成。真要做复杂表单让用户去 opcmenu.com/pro。② 额外题一律生成为**选填**——把新题设成必填会把已经在填的人挡在门外。③ type 不含 COMPETITION（那是外部赛事导入专属，站内报不了名）。④ 线下活动（OFFLINE_GATHERING）必须填 location。⑤ **活动卡上的主办方名**：不传 organizerName 就取你在 App/网页填过的「主办方资料」里的机构名（那个子树要短信验证码，agent 端刻意不做写入口）——两处都空，卡片上主办方那行就不出。联合主办/承办单位直接把完整署名传 organizerName。⑥ 资格不足会返回 error=organizer_profile_required / profile_incomplete / no_published_product，exits 里写了各自怎么补。⑦ 超时重试安全：同 clientRequestId、或同标题 5 分钟内重复调用，返回既有那场而不是再建一场（返回 deduped=true）。

【需要登录】【何时用】改配置前的**读-改-写第一步**，或用户问「这场我是怎么配的 / 报名表都有哪些题」。返回活动本体现值 + 报名配置（题目表 formSchema、外部表单地址、类目、联系方式二维码）+ 我在这场的权限档（myAccess: OWNER / ADMIN / PLATFORM_ADMIN）。 【组合链】本工具读现值 → update_organizer_signup_config(slug) 改报名配置（题目/类目/联系方式）；活动本体（标题/时间/地点/截止/名额）改动走 update_activity。要看报名进来多少人走 list_signup_submissions。 【口径/坑】① activityRef 收 slug 或活动 id 都行。② 只要能读就返回，**活动被下架/取消后照样能读**——报名的人还等着主办方联系。③ 返回里没有任何报名者数据。④ 不返回 learnedPageKeys（客户端学表单的内部账本，对你没用）。

【需要登录】【何时用】用户要改报名表的题目、换报名类目、贴外部表单地址、换答疑群二维码时调它。**立即生效，不留灰度闸**。 【组合链】get_organizer_activity(slug) 读现值 → 本工具传**要改的那几项**（缺省即不动）→ 再读一次确认。改完可以把 signupPageUrl 发给用户去转发。 【口径/坑】① **本工具改不了报名截止时间**——截止在活动本体上，改它走 update_activity。而且：**「截止绝不能提前封口」是这个产品的红线**，把截止改早会把此刻正在填表的人当场挡在外面，任何「提前收口」的请求都必须先跟用户确认清楚后果。② formSchema 是**整表覆盖**，不是打补丁：传了就以你这份为准，漏写的题会被删掉（而且进「不再学习」名单，客户端以后也不会把它学回来）。稳妥做法是先 get_organizer_activity 拿到现有 formSchema，改完整份传回来。③ hostedEnabled=true 而一道题都不给时，服务层会落基线四项（姓名/手机号/微信号/项目介绍），不会留一张空表。④ 投递通道（adapterKey/deliveryMode）是平台侧基建，主办方改不了，也不该改。⑤ 改 signupUrl 会让投递方式跟着重算（有外链→用户设备代填投递；纯托管→站内收）。

按 id 查园区完整详情：补贴明细（类型 / 金额 / 条件）+ 运营方 + 地址坐标 + 入驻主理人 + 渠道 + 信源 + 最近新闻。查不到 found=false。 【口径】园区是**运营维护的目录数据**，站内没有用户打卡/点评（那套 UGC 已下线），别编「有 N 人打过卡」「评分 4.5」这类内容。 【相关】list_city_policies 查所在城市政策红利。

各城市园区总数 + 已运营数（按总数倒序），宏观选址用。传 benefitType 则只统计含该补贴的园区，与列表口径一致。

园区新闻 feed（开园 / 招商 / 补贴变化等时效信息）。可按城市或具体园区过滤。

【需要登录】回应 get_my_work 返回的本人定向合作邀请。接受会加入目标并向合作人公开参与关系；婉拒后邀请不再待处理。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 接受后用 get_collaboration_goal 核对，待回应列表用 get_my_work。

【需要登录】同意或婉拒对方发来的「交换联系方式」请求（exchangeId 从 get_contact_exchange_state 的 PENDING exchange 拿）。accept=true 表示同意：把我的联系方式快照交给对方、同时拿到对方的（结果在返回的 contacts 里），此操作不可撤回——**必须先向用户明确确认**；同意方也需至少一条联系方式。accept=false 婉拒，之后对方可再次发起。重复响应幂等回放。

【需要登录】回应 get_my_dispatch.inbound 中的请求。接受返回既有会话；拒绝会告诉平台双方不合适、可能通知对方并为其重排。先取得用户对回应的授权。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。

查活动列表（线上/线下聚会、讲座、demo day、内测招募，以及 COMPETITION 创业大赛/外部机会）。支持按类型、城市过滤，仅看未来场次，游标分页。 【何时用】用户问「最近有什么活动」「下周有没有线下聚会」「上海有什么创业大赛/机会」时。找大赛/机会用 type=COMPETITION + city。upcomingOnly=true 是大部分情况下你想要的。

【需要登录】列出我作为主办方/管理员能管的全部活动（含已发布 / 已取消 / 已结束 / 被下架），每场带 **submissionCount 报名总数 + pendingCount 待处置数 + myRole 我的角色 + 报名配置概况**。 【何时用】「我那几场活动各报了多少人 / 还有多少没处置」——一次调用就答完，不用再逐场查。改活动或看名单前先用它拿 slug / activityId。 【组合链】pendingCount>0 的那场 → list_signup_submissions 看是谁 → bulk_review_signup_submissions 一次处置完。

【需要登录】取消（下线）我发起的某个活动。已取消 / 已结束的活动不能再取消。

【需要登录】发起人取消自己的需求（终态，不可再重开/编辑）。只是暂时不想展示请用 unpublish_need（可逆），不要用本工具。 【失败语义】非本人 403 not_your_need；已完成 409 need_already_completed；已取消 409 need_closed。

【需要登录】【何时用】要改开场语之前先读现状；或者用户问「别人点找我聊聊时会收到什么」。 【组合链】读完 → 觉得该改就 set_my_chat_opener 写一句更像人说的。写之前先 get_my_card / get_my_products 读一遍他的「我能提供什么」和产品，写出来的话才有具体内容。 【口径/坑】opener=null 表示他没自定义，实际发出去的是 effective（全站默认那句）。这不是「没设置好」，默认那句本来就够用。

【需要登录】【何时用】这是**纯文案活，正是 agent 最该替用户干的事**：读一遍他的「我能提供什么」和产品，替他写一句像真人说的开场白。 【这句话会自动发出去】别人点「找 TA 聊聊」时，服务端会**替你自动发出这一句**作为第一条消息（只在新建会话时发一次，不会刷屏）。所以它是一条**自动广播通道**，不是一条普通私信。 【怎么写】朴素、具体、不做当场能被戳穿的断言。三条硬规矩：① 不写「我懂你想要什么」这类你按按钮那刻根本不知道的话，对方回一句「那你说说」就穿帮；② 不用对仗押韵金句——顺口正是模板和 AI 文案的指纹；③ 说清「我从哪儿看到你的」，这是真的、可验证的，也天然给了对方话头。**不许出现任何「我是 AI 助手 / 自动发送」之类的标识**（产品口径：这就是他本人说的第一句话）。 【组合链】get_my_card（读 canOffer / 产品）→ 本工具写 → get_my_chat_opener 复核 → 之后 start_conversation 开的每个新会话都会自动带上它。传 null 或空串 = 恢复全站默认。 【口径/坑】 · 上限 120 字，超了报 chat_opener_too_long（400，终态，改短再提）。 · **不许夹联系方式和外链**：手机号 / 微信号 / QQ / 邮箱 / http 链接一律拒（chat_opener_has_contact）。这是自动广播面，放开就成了「加我微信卖课」的免费群发口。要换联系方式走双同意的 request_contact_exchange。 · 过敏感词闸（与私信同一把尺），命中报 content_rejected（400，终态，换写法，别原样重试）。

【需要登录】用邮件令牌把某个（爬虫预录的）占位创客号名下的全部产品 + 会话一次性转到当前账号。令牌来自冷启动外联邮件里的链接（/u/{creatorId}?ct={token}）。 【注意】不可逆。与 claim_product（单个产品认领码）不同——这是整号认领。失败返回 ok=false + reason（invalid_token / not_found / already_claimed / self）。

【需要登录】用认领码把一个（管理员 / 爬虫预录的）产品认领到当前账号名下。先过后审：认领后立即发布。认领码一般由管理员发放。

【需要登录】在某个接洽会话里点「完成需求」。**双方各确认一次**：发起人和承接人都要在同一会话里各调一次本工具，双方都确认后该承接才置 COMPLETED；只有一方调过时处于等待对方确认状态（看返回的 authorDoneAt / claimerDoneAt）。 【前置】conversationId 必须是 contact_need 建立的那个会话。确认是真实状态变更，调用前先向用户确认「事情确实办完了」。 【失败语义】非该需求当事人 403 not_party_to_need；会话没绑这条需求 409 no_claim_for_conversation；已完成 409 need_already_completed；已取消 409 need_closed。

【需要登录】校验前置条件后把入驻引导标记为完成（给 onboardedAt 盖戳）。 【前置】必须已选身份 persona；若是创业者（FOUNDER），还需名下至少 1 个产品且 bio 已填（intro 选填不卡），否则报 onboarding_incomplete。 【注意】这是真实状态变更——调用前先 get_onboarding_status 确认各项已就绪，并向用户确认「确实要完成入驻」。

【需要登录】对某条需求「找他聊聊」：与发起人建立 1-1 会话并登记接洽。任何人都能接洽、人数不设上限，需求不会因被接洽而下架。幂等：重复调用只返回已有会话。 【组合链——这是关键】返回 conversationId，直接接 send_message 在该会话继续谈；开聊前可先 get_conversation_needs 一次拿全双方需求上下文。谈妥交付后双方各调一次 complete_need 完成。 【失败语义】不能接洽自己的需求 400 cannot_contact_own_need；404 need_not_found；**429 chat_quota_exhausted = 今天新开会话的额度用完了**（回复老会话不受影响），返回体自带出口，别退避重试。

【需要登录】查看某个 1-1 会话的「交换联系方式」状态：exchange = 最近一次交换（status=ACCEPTED 时 contacts 里双方联系方式互见），myContacts = 我会被交换出去的联系方式，canRequest = 当前能否发起新请求。 【组合链】canRequest=true → request_contact_exchange 发起；对方发起的 PENDING → 与用户确认后 respond_contact_exchange 响应；myContacts 为空 → 先用 add_profile_link 补 contact 组链接（微信/电话/邮箱）。

【需要登录】返回当前用户参与的某个会话的详情（成员 / 关联产品 / 最近预览 / 我的已读位 / 是否静音）。只能查自己参与的会话。读消息用 read_messages。

【需要登录】聊天前情报一步到位：一次调用同时返回 (1) conversationNeed——该会话绑定的接洽需求（含双方完成握手状态 authorDoneAt / claimerDoneAt，判断能否 / 是否该 complete_need）；(2) peerOpenNeeds——对方最近的 OPEN 需求（最多 10 条，了解对方还在找什么，找合作切入点）。没绑需求时 conversationNeed=null。 【组合链】list_my_conversations 拿 conversationId → 本工具补上下文 → send_message 回复 / complete_need 确认完成。只能查自己参与的会话。

按 id 查主理人 profile + 已发布作品列表（按热度+发布时间排序）。 【何时用】用户想了解某位主理人在做什么、关注他/她的全部作品。 【相关 resource】opcmenu://creator/{id}

返回某主理人收到的推荐口碑（无星级，只有文字 + 关系 relation）+ 总数。登录时附带 myRating（我给 TA 的口碑）。 【何时用】人物尽调：谁背书过 TA、以什么关系、说了什么。 【口径】全站至今几乎没有人写过主理人口碑，**空返回是常态**。真要判断一个人靠不靠谱，看 get_creator 的作品列表比看这里有用。写口碑用 endorse_creator。

【需要登录】查看安排路径、建议接洽的人/活动、等待结果反馈的安排和对方来找我的请求。仅服务端灰度已开启的账户可用。此调用会将展示的当前建议标记为已看，影响后台自动换人，故不是纯只读。fillStatus=FILLING 可稍后重查；FAILED 如实报告失败，不自动重新汇报。接受建议用 accept_dispatch_arrangement，反馈用 set_dispatch_outcome。

【需要登录】对已接受的安排反馈用户告知的结果：HELPFUL 有帮助、OK 一般、NO_REPLY 没回复、NO_SHOW 没聊上、NOT_FIT 不合适。可能完成步骤、安排下一步或补排人，消耗平台 LLM 并可能通知。不要根据已读或时间猜测用户结果。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。

【需要登录】关注某位主理人（用户 id）。互相关注即成为好友，对方设为「好友可见」的链接会对你可见。幂等：重复关注 no-op。先用 list_creators / get_creator 拿 id。

【需要登录】【何时用】用户说「这个产品我先存着 / 关注一下 / 回头再看」。关注的是**产品**，不是人（关注人用 follow_creator，那个才影响好友关系和「好友可见」链接）。 【组合链】search_products / list_service_products / get_product 拿到 productId → 本工具关注 → 之后用 get_my_card 看我关注了哪些（关注列表并在名片里，没有单独的列表工具）→ 想找主理人聊就 get_creator → start_conversation。 【口径/坑】幂等，重复关注 no-op。只能关注**已发布**的产品，找不到或已下架报 404。关注是单方面的、对方看不到通知，不算打招呼——真想让对方知道就去开聊。

【需要登录】【何时用】用户说「帮我拉几个朋友进来」「发个邀请给他」，或者开聊额度不够、需要长期加额度时。返回形状几乎就是为 agent 设计的：5 条短信话术 + 2 条微信话术 + 专属短链 + 三段统计（点开 / 注册 / 已入驻）。 【组合链】拿到 smsTemplates / wechatTemplates → **按收件人挑一条**（label 就是场景：通用 / 发给同行 / 发给老朋友 / 发给还没创业的 / 发给投资人媒体）→ 交给用户本人去发（短信从他手机发出去才有人信）。发完隔天再调本工具看 stats.onboarded 有没有涨；额度实况看 get_my_brief 或 chatQuota 字段。 【口径/坑】 · **话术是产品写好的，改写后给用户发，别自己另编一套**——这几条是按「不像群发」调过的（比如「刚想起你」那条交代了发送动机，「不合适就当我没说」那条降低了转化率反而更像真人）。你要改就只改称呼。 · 引荐一位**完成入驻**的同行 = 你每天永久 +1 次开场额度（只注册不入驻不算数，stats 里分开列）。 · 短信正文用 shortLink（省 8 个字符；一条中文短信上限 70 字，超了就分条发、也开始像群发）；微信 / 其它 IM 用 link。 · 引荐码是懒生成的，第一次调用会顺手铸一个，属正常。 · joined 里只给昵称和入驻状态，不给被引荐人的联系方式。

【需要登录】目标发起人向指定站内用户发出合作邀请，会通知对方。必须已有用户对邀请对象和内容的授权。仅支持站内定向邀请；返回不含手机号或可转发邀请令牌。服务会复用尚有效的同人待回应邀请；并发无持久去重保证。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。

【需要登录】把某个会话标记为已读（更新我的 lastReadAt）。

【需要登录】【何时用】用户完成了平台观测不到的**线下动作**：注册了公司、拿到商标 / 软著 / ICP 备案、收到第一笔钱、开始盈利……由他自报，平台不审核（可以顺手把备案号/注册号填进 note）。 【组合链】打完勾返回体自带**涨分回执**（打勾前后的总分与段位、本次新完成了哪些任务）——直接念给用户，别再调 get_my_positioning 前后各拉一次自己减。段位变了就顺势给下一步：get_my_positioning 看新一级的任务，或按 nextUp 的 suggestedTool 直接接着做。 【口径/坑】 · **只有 manual 类任务能打勾**，auto 类（发产品、聊过多少人、发过几条需求）是平台记录算出来的，硬打会 400 task_not_manual——那不是 bug，是防止分数变成自助填空。 · 合法 taskKey（从服务层的 manual 任务集合生成）：build.company（公司注册） | build.trademark（商标注册） | build.copyright（软件著作权登记） | build.copyright_ec（电子软著（电子证书）） | build.icp（ICP 备案） | build.police（公安备案） | build.app_filing（App 备案） | build.mp_filing（小程序备案） | build.llm_filing（大模型 / 算法备案） | build.security_assessment（互联网信息服务安全评估） | build.patent（专利申请） | revenue.first_pay（拿到第一笔收入） | revenue.repeat（有第二个不认识的付费客户） | profit.covered（收入覆盖成本） | growth.ad_basics（学会：一条广告只干一件事） · done=false 是取消打勾（连 note 一起删）。 · 不做任何审核校验：note 就是个备忘，填错也只影响他自己。别拦着用户填。

【需要登录】返回当前用户的通知开关：follows（新增关注）/ dms（私信）/ activities（活动）/ drops（新品播报）/ matches（新需求与我价值匹配时的撮合推送）/ nudge（未读私信触达提醒）。

【需要登录】更新当前用户的通知开关（只传想改的，其余保持不变）。

【需要登录】返回当前用户设置的兴趣标签（用于回显，改前先读）。

【需要登录】设置当前用户的兴趣标签（+ 可选自由描述），用于计算兴趣向量、驱动 personalized_feed 的千人千面排序。一句话即可调教推荐，是个性化读写闭环的写入端。整组替换。

【需要登录】举报违规内容 / 用户。targetType 决定举报对象，reason 是原因。审核后台会处理。

【需要登录】把用户确认的现状/目标交给独行录排安排：首次建路径，后续追加汇报并重排未接受部分。会调用平台 LLM、写入记录，可能后台排人和发通知，需灰度已开启。按用户限流，提示汇报过于频繁时不要立即重试。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 的 reports 核对是否已收到，FILLING 时等候后查询。

【需要登录】在某个会话里以当前用户身份发一条文字消息。先用 list_my_conversations / start_conversation 拿 conversationId。 【注意】这会真的把消息发给对方——发送前请向用户确认收件人和内容。

【需要登录】在会话里转发一张站内卡片（与 App 聊天里的「名片/需求卡转发」同源）：type=owner 转某位主理人的名片（把「我自己的名片」发给对方 = 用 get_my_profile 拿到自己的 id 再转），type=need 转某条需求卡。标题/头图/链接由服务端从库里重建可信快照，不接受自定义内容。 【注意】这会真的把卡片发给对方——发送前请向用户确认收件人和卡片对象。

【需要登录】取消关注某位主理人。幂等：未关注时也返回 ok。

【需要登录】【何时用】用户说「这个不用留着了」。 【组合链】get_my_card 看当前关注了哪些 → 本工具取关。 【口径/坑】幂等，本来就没关注也返回成功（不报错）。对方永远看不见你关注过或取关过。

【需要登录】接受 get_my_dispatch 的建议。MEET 会真实建会话并以本人名义发送 opener；省略 opener 会发送平台预写开场白，先展示内容并取得用户授权。ATTEND 会尝试报名，但本工具不证明报名成功，始终返回 signupVerificationRequired=true；按 next 用 get_signup_activity 核对实际报名方式和状态，必要时 list_my_signups 核对投递结果。hasSignupRecordHint 仅表示有记录，可能只是外部留资、投递失败或取消；openSignupSlug 为空也不证明完成。外部表单仍须完成源站提交，缺资料时再用 submit_signup。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 服务只对完成后的重复接受短路，不保证并发去重。

【需要登录】拉黑某用户：双方互不能私信，并自动解除互相关注。处理骚扰时用。幂等：重复拉黑 no-op。

【需要登录】列出当前用户拉黑的所有用户。

【需要登录】【何时用】任何「今天怎么样 / 有什么要处理的 / 日报 / 早上问一句」的场景**都从这里开始**。它把 App 里分散在六屏、且必须由用户自己想起来去点的六件事并成一次返回： ① 未读私信数 ② 最近 7 天谁看过我（计数 + 具名前几位）③ 今日开聊额度 ④ 7 天内截止且我还没报的场次 ⑤ 定位栏「最该做的三件事」⑥ 我办的活动待审报名数。 这是 agent 面独有的形态——App 里没有、也不该有这一屏；一次调用换一段话。 【组合链】 · unread>0 → list_my_conversations 找出是谁 → read_messages 看内容 → send_message 回。 · attention.top[].viewerId → get_creator 看他是谁 → start_conversation 主动开聊（这是全站转化最高的一条链）。 · deadlines[].slug → get_signup_activity 看要填什么 → submit_signup 报名。 · positioning.nextUp[].suggestedTool 就是「这件事该调哪个工具」，用户说「把这周能做的都做了」就照着一条条真做完再汇报。 · organizer.activities[].slug → 去主办方那条链审报名。 · 合作目标、合作任务与待回应合作邀请不在这六路里，用 get_my_work；安排路径与结果反馈用 get_my_dispatch（该读取会标记建议已看，不要后台顺手调用）。 · chatQuota.remaining=0 时别再张罗开聊，先 get_my_invite（引荐一位完成入驻的同行 = 每天永久 +1 次）。 【口径/坑】 · 六路**并发取，任何一路失败都降级成 null**，整体永不失败。哪几路挂了写在 degraded[] 里——null ≠ 0，别把「取不到」说成「没有」。 · 未读数、额度、待审数都是**实时推导**的，没有重置任务；额度不会在白天自己回来。 · 具名访客只有真人登录后浏览才认得出；anonymous 那部分**没有身份可查**，是计数下限（按 ipHash 折叠），不许编人名。 · 报名 feed 服务端是「置顶优先、再按截止近的排」，这里已按截止时间重排并只留 7 天内、我还没报的。 · **不是纯只读**：定位那一路走的是不落算分快照的算法，但没有新鲜阶段结论时会在后台排一次 LLM 阶段重判并写回结论。所以标了 readOnlyHint=false。代价有硬闸：结论 7 天新鲜期内不重判、同一人 10 分钟内只排一次、证据没变不重判——**当日报天天调、定时调都不会放大成本**，放心调。 · 要完整任务清单（39 条的完成态）用 get_my_positioning。

【需要登录】【何时用】用户说「把做 AI 的都入围、其余候补」这类整批操作时调它。**这是 agent 相对 web /pro 最大的效率差**：那边要勾 200 个复选框。 【组合链】list_signup_submissions(slug, q='Agent') 拿 ids → 本工具 preview=true **不落库**，返回「将被改的 id + 昵称 + 当前状态」念给用户 → 用户确认后 preview=false 真正执行 → 剩下的人换个 reviewStatus 再来一次。 【口径/坑】① **执行前必须把名单念给用户确认**——处置结果报名者在「我的报名」里立刻看得见，改错了收不回来。preview=true 就是为这一步设计的（它是 App 那个确认弹层在 agent 端的形态，不是可以省掉的一步）。② 返回体自带 diff：requested / updated / ignoredIds——不属于这场活动的 id 会被服务层**静默忽略**，传 200 个只改了 197 个时，是哪 3 个掉了这里如实告诉你。③ reviewNote **不接受空串**（zod 直接封死）：批量清空 200 条留言且无处恢复，风险太高；不传就是不动。④ 一次最多 200 个 id。⑤ 只动报名结果，不碰投递状态。

【需要登录】一次调用拿全「我是谁」的结构化全集：基本信息（含 canOffer 我能提供什么）+ 按分组聚合的全部链接（标注每条可见范围）+ 已发布产品 + **多角色画像 roleProfile**（融资/投资人/机构/资源寻找者/在校/阶段）+ 我关注的产品。 【何时用】写开场白、填外部平台的表单、生成 BP 大纲、判断该不该接某条需求——这些事都要先有这一份。**别为了凑齐这些信息去连调四五个工具，这里一次给全。** 【组合链】get_my_card → 拿 canOffer 对照 list_needs_feed 挑能接的 → contact_need → send_message。 【想改】资料本体走 update_my_profile；角色画像走 set_my_role_profile；也可以用 resource opcmenu://me/card 拿同样数据。 【完整度】missing 列出还没填的关键项（照名片完整度口径），是「还差哪几步」的现成代办清单。

各城市 / 区的创业政策红利（政策大礼包：标题 / 发文单位 / 日期 / 亮点 / 信源）。 【何时用】「深圳 OPC 有什么政策红利」「入驻前看看当地政策」。不传 city 返回全部。

列出已发布的一人公司主页（最新优先）。可选 q 关键词命中名称 / 定位。 【何时用】用户想浏览「有哪些一人公司」或按关键词找公司。drill-down 用 get_company。

【需要登录】列出当前用户的所有私信会话（含未读数 unread、最近一条预览、成员信息）。先用它拿 conversationId 再 read_messages / send_message。 【两种会话】type=DM 是一对一私信；type=GROUP 是平台的破冰介绍群（系统把两位可能互相有用的人和官方号拉在一起，带 title 和成员列表）。**群里不做交换联系方式**，要联系方式在 DM 里走 request_contact_exchange。 【未读】每条自带 unread，别再去找什么「未读总数」工具，加起来就是。

【何时用】用户想看「有哪些做一人公司的人」「最热门的主理人」时。返回主理人卡片：昵称 / 头像 / 简介 / 作品数 / isStub（是否爬虫导入占位号，false=已认领真人）。 【后续 drill-down】可以接 get_creator 看某位主理人的完整作品列表。

【需要登录】拒绝尚未接受的建议。SWAP 换一个；WRONG_DIRECTION/OTHER 可能重排；HAVE_ALREADY/NOT_NOW 跳过这一步。可能调用平台 LLM、后台排人和通知。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对新安排。

【需要登录】列出当前用户的 agent / CLI 接入设备（名称 / 客户端 / token 末 6 位 / 创建·最近使用·过期·吊销时间）。吊销某台用 revoke_my_device。

【需要登录】给某位主理人写一段推荐口碑（无星级，文字必填 ≥4 字，可选关系 relation）。不能给自己 / 未认领占位号写；互相拉黑时不可写。一人对一人一条，再次调用即编辑。

【何时用】一个工具两个透镜，用 side 切：side=investor 找**投资人**（个人/产投/机构），side=project 找**在融资的项目**。用户说「帮我找看 AI 应用的天使」走前者，「最近有哪些一人公司在融钱」走后者。 【组合链】items[].user.id → get_creator 看完整主页 → start_conversation 开聊（开聊走每日额度，撞 429 会直接返回「怎么办」的出口，别重试）；user.id → follow_creator 先关注不打扰；items[].company.slug → get_company；side=project 时 items[].product.slug → get_product。想让投资人反过来找你，用 set_my_role_profile(fundraising) 把自己挂上这个榜。 【口径/坑】 · 轮次（round）是对**自由文本**做的宽松包含匹配，不是结构化字段——「A 轮」「A」「Pre-A」全靠字面碰。别对用户吹「精确筛选」，也别拿它当统计口径。参考写法：种子 / 天使 / Pre-A / A 轮 / B 轮及以后。 · side=investor：老账号 / 运营种子机构号大多没填结构化 investor，type 是从 personaTags + canOffer 里**猜**出来的（只用于筛选展示，不反写）。所以 type 筛出来的结果里有推断值，不是本人自报。 · side=project：主召回是 roleProfile.fundraising.active=true，另外补量了「发了 FINANCING 需求的人」——那批人 fundraising 会是 null 而 financingNeed 有值，别当数据缺失。 · **BP 拿不到**：项目卡只给 hasBp 布尔（有没有传过 BP），别人的 BP 文件链接永远不出现在返回里。不许去猜路径、拼 URL 或让用户「试试这个地址」。要 BP 就让用户去跟对方开聊要。 · 规模很小（百级），召回后内存过滤；分页同样是 offset。

【需要登录】【何时用】用户说「把报名表给我 / 导出名单 / 我要下载 Excel」时调它。返回一条**一次性签名下载链接**，用户自己在浏览器里打开就下载 CSV。 【组合链】list_signup_submissions 先给用户看数量和概览 → 确认要整份表格 → 本工具铸链接 → 把 url 原样发给用户。想按人处置不需要导出，直接 bulk_review_signup_submissions。 【口径/坑】① **绝不返回 CSV 正文**：一次最多两万行、每行带解密后的手机号微信号，那种东西不该进模型上下文。工具只给链接。② 链接**10 分钟有效、且只能成功打开一次**——换过一次即废（它被转进工作群就等于整份手机号裸奔，所以是真一次性）。用户没在 10 分钟内打开就再调一次。③ 提醒用户：这份表里全是报名者的联系方式，别往群里转发。④ 打开链接时会再校验一次权限（票只证明 10 分钟前你有权限，不是授权本身）。⑤ 撞顶两万行时 CSV 末尾会有一行中文说明，让用户看一眼。

【需要登录】把当前用户某条链接（按 url 匹配，可加 type 限定）的可见范围改成 public/friends/private。 【例】「把我的手机号改成仅自己可见」。

【需要登录】读取某个会话的消息。默认返回最近若干条（倒序，含 nextBefore 游标向前翻）；传 after=<messageId> 则增量拉取该消息之后的新消息（正序，用于轮询）。只能读自己参与的会话。

【需要登录】返回当前用户的关注 / 粉丝 / 好友（互相关注）列表与计数。

【需要登录】返回当前用户的入驻引导状态：completed（是否已完成）/ persona（身份）/ isFounder / creatorType（创造者类型）/ hasProduct（名下是否有产品）/ hasProfile（bio 是否已填；详细介绍 intro 是选填，不算门槛）/ hasCompany（是否建了公司）。 【何时用】帮用户「完成入驻 / 看还差哪步」时第一步先读它，再按缺口补：选身份(set_persona)→发产品(create_product)→完善资料(update_my_profile，**记得写 canOffer**)→可选建公司(create_company)→complete_onboarding。 【prefill——别从零开始问】返回里可能带 prefill：这个人此前在网页上报过名、或被运营在现场当面录过资料，服务端手里就有一份现成的（含 LLM 通读其报名答卷得出的 understanding 要点）。有它就**当上下文用，能少打很多字**。 ⚠ **预填只减打字，不减追问**：每一项都要念给用户确认，必填项一项都不能跳，`complete_onboarding` 的校验一条都不能绕。prefill 为 null 是常态（大多数人没有）。

浏览 / 筛选 OPC 园区目录（六城）。 【杀手用法】按补贴类型筛：benefitType=RENT_SUBSIDY 找「有租金补贴的园区」——这是主理人/找资源者最高频的诉求。可叠加 city / track / 状态 / 关键词。 【drill-down】get_park 看补贴明细 + 入驻条件 + 信源。

【何时用】用户想找「人」时——「找能提供小程序代开发的主理人」「谁懂跨境电商供应链」「找人合作做 AI 出海产品」。搜的是主理人的供给侧（canOffer 能提供什么 + 昵称/介绍/身份标签），这是 OPC 之间撮合合作的刚需入口。 【机制】关键词 + 向量混合检索（RRF 融合），真人（已认领）梯队前置。结果含 canOffer / similarity / claimed。 【组合链】命中后 get_creator 看作品尽调 → start_conversation 开聊；对方若发过需求也可 contact_need 顺着需求接洽。搜「产品」用 search_products，搜「需求」用 search_needs。 【常见 pitfall】**不支持按手机号搜人**（隐私保护，服务端对手机号查询恒返回空）——用户给的是手机号时直接说明不支持，改问对方的昵称或能提供什么。

【需要登录】设置当前用户的身份 / 来意 persona。可选：GENERAL_PUBLIC（随便看看）/ FOUNDER（发布项目）/ INVESTOR（投资）/ MEDIA（观察趋势）/ RECRUITER（招聘）/ SERVICE_BUYER（买服务）/ PARTNER（谈合作）/ OTHER（其它，需填 personaOther）。 【多重身份】可同时是多个身份（如 主理人+投资人）：persona 是主身份，personas 传全部身份。**注意：这是整组替换——不传 personas 会把用户已设的多重身份收缩成单身份**，改之前先用 get_my_profile 看现状。 【创业者分叉】persona=FOUNDER 时可顺带传 creatorType（创造者类型），驱动默认产品分类与后续填写提示；非创业者忽略。

返回千人千面的发现 feed：登录且设过兴趣（set_my_preferences）时按兴趣语义排序，否则回落「已认领优先 + 热度」。比 random_feed 更贴合用户口味，是网页登录后的默认发现页。续拉时把 nextCursor 原样回传以延续同一副牌。

【需要登录】【何时用】用户问「我现在到哪一步了」「接下来该干嘛」「帮我把这周能做的都做了」。返回五级主线的当前等级、六维画像、称号与总分，以及全部任务的完成态与 nextUp（最该做的三件事）。 【组合链·代办】nextUp 里每条任务都带 suggestedTool——**这是 agent 面相对 App 的关键差别：App 的 CTA 只能把人跳到那一屏让他自己动手，你能直接把这件事做完。** 对照表： · 写「我能提供什么」/ 一句话说清项目 → update_my_profile(canOffer)（partner.can_offer 与 funding.one_liner 两条任务判的就是 User.canOffer 的字数，分别 ≥30 / ≥20 字，写虚了过不了） · 融资资料、轮次金额、传 BP → set_my_role_profile(fundraising) · 邀请同行 → get_my_invite · 发需求（招兼职 / 找合伙人 / 找资源）→ create_need · 发布产品 → create_product · 归位产业链 → set_my_chain_position · 看看我的名片长什么样 → get_my_card；去回消息 → list_my_conversations 用户说「把这周能做的都做了」就真的一条条做完再汇报，别只念清单。 【口径/坑】 · **本工具会刷新你的定位快照**（写 PositioningState：算分快照 + auto 任务的完成戳），所以它不是纯读工具，别当免费接口循环调。只想看个大概用 get_my_brief。 · level.source='declared'（用户自报）**永远优先**于 inferred（LLM 读证据判的）/ observed（确定性兜底）。要改自报值走 set_my_role_profile(venture.stage)。 · basis / signals / confidence 是 LLM 给的判词，**转述它，别自己另判一个等级**，更别说「我觉得你其实已经到 XX 了」。 · 任务只增不减：达标那刻盖戳，之后数据回落也不打回未完成（用户不会莫名其妙掉级）。 · 默认**裁掉全部 39 条任务的培训正文（guide）**，否则一次调用几万 token。真要看某一条的正文：includeGuides=true 且必须同时给 taskKey，只取那一条。 · verify='manual' 的任务平台观测不到，要用 mark_positioning_task 自报打勾。

按 id 查内容流里的单条（正文 / 图片视频 / 挂卡 attach / 作者）。登录时附带 viewerHasLiked / isMine。 【口径】绝大多数是官方生成的内容（每日选品 / 赛事导入），不是用户动态；评论区全站至今零条，别向用户提「去评论区看看」。

独行录的**官方内容流**：每日发现选品、创业大赛机会、园区与政策资讯。 【何时用】用户想看「最近站里推了什么」「有哪些新的创业大赛机会」时；也可以传 attachType+attachId 查挂在某产品/活动/园区上的相关内容。 【重要口径——别说成社区】这不是用户社区：站内**没有用户发帖入口**（App 的动态 tab 已换成产业链），流里几乎全是系统生成的官方内容。别向用户描述成「大家在聊什么」，也别建议用户「去发个动态」——没有那个入口。 【feed】recommend（默认）| following（只看我关注的人，需登录；因为几乎没有用户帖，这个流通常是空的）。

【何时用】用户说「随便看看」「让我发现些有意思的」「给我推荐点东西」时。随机抽 已发布 的产品（已认领主理人的产品优先出现）。比 search 更适合「我也不知道我想要什么」场景。续拉时把已看过的产品 id 传进 exclude 去重。

【需要登录】给某产品打 1–5 星 + 可选文字评价（一人一产品一条，再次调用即编辑）。不能评价自己的产品。先用 get_product / search_products 拿 productId。

【需要登录】删除当前用户对某对象（产品/园区/主理人）的评价（幂等：没有则 no-op）。

【需要登录】【何时用】用户问「最近有人关注我吗」「谁看了我的产品」，或者你要给他找**主动开聊的由头**时。三路合并：产品被浏览 / 主页被浏览 / 需求作者页被点开。 【组合链】这条链是本工具存在的全部理由，App 里要三次点击两次跳转： named[].viewerId → get_creator 看他是谁、在做什么 → start_conversation 开聊（开场语可以直接引用 named[].what：「看到你翻了我那条 XX」，这是真的、可验证的话头）。要先看看关系 → get_relationship；不想立刻打扰 → follow_creator。 【口径/坑】 · **匿名那部分只是计数，没有身份可查，也不许编。** anonymous 是按 ipHash 折叠后的**下限**，不是精确人数。 · 具名访客要求对方登录状态下浏览；查不到人（注销 / 占位号）的会被降级计进 anonymous，所以 named 恒少于真实关注量。 · 机器流量已剔（站内约 41% 的产品浏览是爬虫），自己看自己也已剔。 · 默认窗口 7 天。窗口拉太长会翻旧账——两周前看过你一眼的人，你现在去搭话是尴尬的。 · 每天有具名访客的人本来就少（生产实测每天 2~12 位主理人），空返回是**常态**，如实说「这几天没人来看」，别改参数反复试。 · named 最多回 limit 条（默认 20，最近的在前），namedCount 始终是**窗口内的真实总数**——两者不等时 truncated=true，别拿 named.length 当总人数。

【需要登录】【何时用】只在开聊额度用尽、用户**明确要求**今天就多聊一个人时。花 500 积分换今天 +1 次开场，每日限 1 次。这是应急安全阀，不是常规出口。 【必须先征得同意】**agent 不许自动兑换**。先把「这要花 500 积分」原话念给用户，拿到明确同意再调。撞额度墙时 start_conversation / contact_need 的失败返回体里已经带了这个出口和你的余额，照着念即可。 【组合链】兑换成功 → 立刻 start_conversation 把这一次用掉（额度只加今天，过夜作废）。不想花积分 → get_my_invite 走引荐（那是永久加额度，兑换只加一天）。 【口径/坑】 · 两种失败都是**终态，绝不重试**：409 insufficient_points（余额不够）/ 409 chat_quota_redeem_limit（今天已经兑换过了）。返回体里会带上当前额度和余额，直接转述。 · 如果你刚调过一次然后超时了，再调撞到 chat_quota_redeem_limit —— 那说明**上一次其实成功了**（每日上限靠全表唯一键原子兜底）。读返回体里的 quota 确认，不要当失败。 · 额度只拦「新开一个会话」；回复老会话、别人来找你都不受影响。 · 积分体系 2026-07-03 已从用户面下线，这是全站唯一一个还露在 agent 面的积分动作。别去找别的积分工具，没有。

【需要登录】返回当前用户与目标用户的关系：following（我是否关注 TA）/ followedBy（TA 是否关注我）/ isFriend（互相关注）/ isSelf。决定是 follow 还是已是好友（好友可见对方「好友可见」链接）。

【需要登录】把手动下架过的需求放回信息流（与 unpublish_need 成对，免费、可反复切）。 【失败语义】非本人 403 not_your_need；已取消/完成的不可重开 409 need_closed（那种情况请用 create_need 重新发布）。

【需要登录】在 1-1 会话里发起「交换联系方式」请求：对方同意后，双方的微信/电话/邮箱等联系方式互见（各自快照，之后改资料不回溯）。要求自己至少填了一条联系方式（no_contact_info 时先用 add_profile_link 补 contact 组链接）。已交换过会报 already_exchanged；对方已有待处理请求会报 peer_request_pending（此时应改走 respond_contact_exchange）。自己重复发起幂等回放。 【注意】这会真的向对方发出请求消息——发起前请向用户确认。

【需要登录】【何时用】用户对某一个人下结论（入围/候补/未通过）时调它。**处置结果报名者在「我的报名」里看得见**，reviewNote 是直接给他看的一句话。 【组合链】list_signup_submissions 定位 → get_signup_submission 看清这个人 → 本工具处置。一次要处置很多人用 bulk_review_signup_submissions（那边有 preview 可以先过目）。 【口径/坑】① 执行前把「谁 → 改成什么」念给用户确认——报名者那头会看到。② reviewNote 缺省=不动之前写的留言，传空串会**清空**它。③ 只动报名结果，不碰投递状态（那是「有没有投到源表单」，两码事）。④ 取值：PENDING（待初审） | REVIEWING（初审中） | SHORTLISTED（已入围） | WAITLIST（候补） | REJECTED（未通过） | WITHDRAWN（已撤回）。

【需要登录】吊销当前用户的某台接入设备（其 token 立即失效）。先用 list_my_devices 拿 deviceId。返回 revoked 是否实际吊销了一条。

【需要登录】【何时用】用户在对话里透露了角色信息就顺手写进去：在融资（轮次/金额/要求）、我是投资人（类型/关注轮次/单笔规模/赛道）、我代表机构（园区/赛事/企服，能给什么资源）、我是来找人的媒体/HR/采购/合作方、我还在上学、我的创业阶段变了。这些字段决定他出现在首页哪个 tab、被谁搜到。 【组合链】写完 fundraising.active=true → 他就进了 list_funding(side=project) 的池子，可以马上 list_funding(side=investor) 找对口的钱 → get_creator → start_conversation。写完 investor → 反过来出现在别人的 list_funding(side=investor) 里。venture.stage 改完 → get_my_positioning 会给出这一级的新任务清单。 【口径/坑】 · **本工具已做好逐字段合并**：只传你确知的那几个字段即可，没传的老值原样保留。（服务层本身是「顶层键整体替换」，直传 fundraising:{round:"A"} 会把 amount/requirements/BP 一次抹掉——这里先读后并挡掉了这个坑。） · 想**清空**某个字段：传空字符串或跟用户确认后整棵子树重传，不要靠不传来清空。 · venture.stage 走特殊路径：它同时是定位栏的主线阶段，本工具会调专门的写入口（传 null = 撤销自报，系统当场重判一次并把判词带回来）。取值：idea（找想法） | build（开发产品） | launch（产品上线） | revenue（有收入） | profit（有盈利）。 · **主办方资料（orgName/联系人/联系电话）不在这里**，本工具写不了也不该写：那是唯一一条带短信验证码的通道，绕过它就是让 agent 能冒名办活动。用户要改主办方资料，请他去 App 里改。 · 自由文本会出现在公开卡片上（等同 UGC 广播面），过敏感词闸，命中报 content_rejected。 · 返回的是**变更回执**：哪几棵子树被合并了、合并前后各是什么。念给用户听，别只说「已更新」。

【何时用】用户要**买一类服务**而不是找某个具体产品时：「GPU 租赁」「代理记账」「商标代办」「法务咨询」「找人帮我投流」「大模型 token 哪买便宜」——这是高意图检索的正确入口。按服务域精确取整组，比 search_products 关键词碰运气稳。 【组合链】items[].id → get_product 看详情 / follow_product 关注跟进；items[].owner.id → get_creator 看这家谁在做 → start_conversation 直接开聊；整组翻完都不合适 → create_need 发一条需求（needType=RESOURCE）让服务商反过来找你。 【口径/坑】 · 这是**目录**不是搜索：没有相关度排序。顺序 = 已认领梯队优先 → 站内推广位 → 发布时间。所以第一屏未必最匹配，看 tagline 自己挑。 · sub 必须落在 domain 那一组里；给了外组的 sub 服务层**不报错**，会静默退回整组结果（防止用 sub 越权掏另一组）。别把「返回了一堆不相干的」当成数据问题。 · 空结果是常态：不少子类目前站内确实没有供给，如实说「这一类还没有」并转 create_need，别改词反复重试。 · 分页用 offset（nextCursor 就是下一次的 offset 字符串），不是 id 游标。

【需要登录】返回某对象的分享卡 manifest：**shareText（现成的分享文案）+ link（落地页链接）**，外加卡片页数/版式元数据。agent 帮用户「把我的主页/需求分享出去」时用它拿文案和链接，可直接转发到任何渠道。 【kind 取值】owner（主理人主页卡，id=用户 id，自己或他人皆可）| need（需求卡，id=需求 id）| card（我的个人名片卡，仅本人，id 固定传 "me"）| position（我的定位卡，仅本人，id 固定传 "me"；定位栏唯一的分享出口）| onboarding（入驻完成卡，id 固定传 "me"）。 【注意】返回里没有图片 URL——卡片图片的渲染接口是登录态 + private 缓存的站内接口，不要自己拼 image URL 当公开资源发给第三方；对外分享一律用 shareText + link。 【失败语义】对象不存在返回 found=false；kind=card / onboarding 而 id 不是 "me" 报 403。

【需要登录】【何时用】用户问「我报过哪些 / 那个赛事结果出来没 / 主办方回我了吗」时调它。一次给全：我报过的所有场次（最多 50 条，新的在前）＋ 每一场的投递状态与**主办方处置结果**（reviewStatus：PENDING（待初审） | REVIEWING（初审中） | SHORTLISTED（已入围） | WAITLIST（候补） | REJECTED（未通过） | WITHDRAWN（已撤回））＋ 主办方留言 reviewNote。App 上这是「我的报名」那一屏。 【组合链】看到某场 reviewStatus=SHORTLISTED 或 reviewNote 里要求补材料 → get_signup_activity(slug) 看还缺哪几题 → submit_signup(slug) 补交（重新提交会覆盖上一版）。想一次盘所有在报的场次还缺什么 → get_signup_gaps。 【口径/坑】① 默认**不返回答案全文**（50 条里全是本人的手机号/微信/证件字段，没必要整份灌进上下文），只给答了哪几题的 key 列表；确实要看内容再传 includeAnswers=true。② submission.status（SUBMITTED/DELIVERED/DELIVERY_FAILED…）是「有没有投递到源表单」，reviewStatus 才是「主办方录不录你」——两者严格分离，别混着念。③ DELIVERY_FAILED 不是「你被拒了」，是代填投递没成功，让用户去报名页手动补交。④ PENDING 只是主办方还没处置，不代表落选。

【需要登录】用户明确表示这步自行搞定/不再需要时跳过，终结该步骤未接受建议并推进后续步骤，可能触发平台 LLM 排人。结果不明或超时后先查询现值，不要自动重发；服务没有持久请求去重键。 用 get_my_dispatch 核对。

【需要登录】与某位用户开启 1-1 私信会话（已存在则返回原会话，幂等）。可选 productId 标记围绕哪个产品咨询。不能和自己开会话。先用 get_creator / search_people 拿对方 userId。 【返回】conversation（含 id）+ created（这次是不是**新建**的）+ openerSent（服务端是否已自动替你递了开场语）+ opener/openerKind（你设过自定义开场语就带原文 kind=custom；没设时服务端按对方的产品现生成一句，kind=product/generic，原文不回传，别编）。**created=true 且 openerSent=true 时对方已经收到你的开场语了，别再重复问一遍好**——接着说正事即可。开场语内容用 get_my_chat_opener 看，改用 set_my_chat_opener。 【每日开场额度】只有**新建**会话才占额度（回复老会话、别人来找你都不占）。撞上限时返回 429 chat_quota_exhausted，且返回体里直接带出口（额度实况 / 引荐短链与话术 / 积分兑换报价）。**那不是临时故障，今天的额度不会自己回来，不要退避重试**——照返回里的 exits 跟用户说清楚。

【需要登录】【何时用】用户说「帮我报这场」时调它。只传**这次要新填/要改的答案**即可：handler 自己会先读一遍我在这场活动的全部现值（上一版提交 + 跨表单复用的资料覆盖层 + 主页/公司/产品推导），打上你的补丁后提交**全集**。 【组合链】get_signup_activity(slug) 看 viewer.missingRequired → 照 label/hint/options 问用户 → 本工具 answers=[{key,value}] 提交 → 返回的 submission.reviewStatus 之后用 list_my_signups 跟进。撞「已截止」时返回体自带还能报的替代场次（照 exits[].detail.alternatives 里的 slug 再走一遍 get_signup_activity）。 【口径/坑】① **省略 ≠ 清空**：这是 agent 通道相对客户端的刻意差异——客户端有确认页（用户亲眼看着自己清掉了微信号），agent 没有，所以这里不继承服务层「传了 answers 就以 answers 为全集、没传的一律置空」那条语义。要真的清空某题，把 key 放进 clearKeys（它会连跨表单复用层里那一行一起删掉——否则下次报别的表又会被解析回来；文件行不删）。② type=file 的附件题（BP/营业执照）**agent 传不了**，会被整键省略以保住用户此前传过的文件——绝不许把文件名或一个链接当答案填进去。③ 合并后仍缺必填项时**不会提交**，直接返回 error=missing_required_fields ＋ 逐条「要问用户什么」，把这些问完再调一次。④ 返回 delivery.kind='webview' 时**报名还没投到主办方源站**，站内只存了留资和代填答案——此时**逐字禁止**对用户说「已报名成功」，必须说「站内已留档，还要在主办方表单上完成提交」，并把 delivery.url 给他。⑤ 重新提交会以合并后的全集覆盖上一版。**证件号这类敏感题的明文是加密存的、读不回来**：上一版填过而这次没给值时会直接拒绝提交（sensitive_answer_would_be_wiped），因为提交上去就会把它覆盖成空且不可恢复——按返回里的 exits 让用户重说一遍，或者明确不要了就放进 clearKeys。⑥ channel 恒为 'agent'，主办方在报名单里看得见这笔是 agent 代提的。

【何时用】用户要的是**某一类人本人**而不是某个产品/服务时用：「帮我找个能写代码的」「有没有做出海的人」「找几个律师/财税顾问聊聊」。和 list_service_products 的区别：那边是「他卖什么」（产品目录），这边是「他本人是干什么的」（人的目录）；和 search_people 的区别：那边是语义搜，这边是结构化职业筛选，适合按类目扫一遍。 【组合链】items[].user.id → get_creator 看完整主页 → start_conversation 开聊（开聊走每日额度，撞 429 会直接返回「怎么办」的出口，别重试）；user.id → follow_creator 先关注不打扰；items[].company.slug → get_company。人卡唯一动作就是进个人主页，没有别的落点。 【口径/坑】 · 职业（items[].professions）是**机判闭集**：由资料/名片/自述跑分类器写入，不是本人勾选；一人最多两个主职业。没被判出职业的人不进这个目录，想找他走 search_people。 · chip 是职业的合并桶（比如律师/财税/HR 都并在「咨询·顾问」里），卡片上的职业胶囊是细粒度标签，两者不是一回事。 · **chip 全集以 GET /v1/talent/chips（首页下发）为准**：服务端按真实人数 ≥ 阈值才下发，这里的枚举只是合法值集合，不代表此刻每个都有人。传了没下发的 chip 会拿到很少甚至 0 条，不是报错。不传 chip 或传 all = 全部；传不认识的 key 按全部处理（不 400）。 · 只回真人（在册、已入驻、非测试号、非运营机构号）；返回里没有手机/邮箱/外链，要联系只能开聊。 · 规模小（百级），分页是 offset（nextCursor 就是下一次的 offset）。

【需要登录】上报一个追踪事件（点击 / 浏览 / 分享 / 下载 等）。targetType + targetId 决定目标对象，type 是动作。 【常见用法】当 agent 帮用户完成「分享某产品」「点开某主理人主页」时记一笔，让推荐算法更准。 【type 例】 view | click_link | share | download | follow

【需要登录】取消对某用户的拉黑。幂等：未拉黑时也返回 ok。

【需要登录】把自己的需求移出信息流（状态与接洽不变、不删除）。需求不会因被接洽或时间流逝自动下架，想暂时不展示就用它。之后可用 reopen_need 免费重新展示，两者成对可反复切。 【失败语义】非本人 403 not_your_need；已取消/完成 409 need_closed。

【需要登录】把一张公开可访问的图片 URL 镜像进独行录存储，返回稳定的图片地址。 【何时用】要给「我的头像 / 产品 logo / 产品封面 / 产品图集 / 活动封面」设图时：先用本工具把外部图片 URL 转成独行录地址，再把返回的 url 填进 update_my_profile(avatarUrl) / update_my_product(logoUrl·coverUrl·gallery) / create_product / create_organizer_activity(coverUrl·posterUrls)。 【限制】仅支持公网 http(s) 图片，带大小/类型/SSRF 校验。

【需要登录】查看独行录合作目标、待我做/我派出的任务、待回应合作邀请。任务保留目标与指派人，便于持续跟进。目标列表最多返回 limit 条并给总数，goalOffset 按 nextOffset 翻页（只影响目标列表）；任务 reachingLimit=true 时可能还有，按 goalId 调 list_collaboration_tasks 查看。邀请最多 50 条。读任务会幂等补齐周期任务的期次，故不是纯只读。不会读取或标记安排。下一步：get_collaboration_goal 看目标详情；set_collaboration_task_status 回报进展；respond_collaboration_invite 回应邀请；安排另用 get_my_dispatch。