我的今日全景
get_my_brief【需要登录】【何时用】任何「今天怎么样 / 有什么要处理的 / 日报 / 早上问一句」的场景都从这里开始。它把 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 → 去主办方那条链审报名。 · chain.unplacedCount>0 → 念出 chain.unplaced[] 里那几个名字 → 逐个 set_my_chain_position 补齐（要看每个锚点的链位原文先 list_my_chain_anchors）。 · cooperation.awaitingMyReply>0 → cooperation.top[] 里就是谁在等 → get_cooperation_request 读全文 → respond_cooperation_request（要全量清单去 list_my_cooperation_requests）。 · 合作目标、合作任务与目标邀请不在这八路里（那是另一套），用 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 分钟内只排一次、证据没变不重判——当日报天天调、定时调都不会放大成本，放心调。 · chain 只给名字和链位标题（摘要面）；要 summary / 全部链位原文去 list_my_chain_anchors，要上下游才去 get_chain_anchor（那个真花钱）。 · cooperation 区分 awaitingMyReply（别人在等我）与 awaitingTheirReply（我在等别人）——催谁完全不同，别混成一个「有 N 条合作」；awaitingSecretaryRelay 是发给云用户、由独行录人工小秘书转达中的，对方不在站内，别说成在等 TA 回。 · 要完整任务清单（全部任务的完成态）用 get_my_positioning。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||