🎯 [feature][P1] Grok X 搜索 informant for A站马 (调研报告) — #205 场景 1

[s2agi]

🎯 场景 1 — Grok X 搜索 informant (for A站马 调研)

Sub-task of #205 (goal: anet 优雅完整支持 grok-build runtime)
当前 blocked on: #204 attribution 修完
Owner pending: TBD（待 Vincent 派）

目标

让 grok-build runtime 节点能调用 Grok CLI 自带的 X (Twitter) 搜索能力，作为 A站马（内容/调研负责人）的高质量信息源。

典型用法：

• A站马接到一个调研任务（例如"过去 7 天 AI Agent 领域社交媒体讨论热点"）
• A站马 commhub_send_task 派给一个 grok-build 节点
• grok 节点用 Grok CLI 的 X 搜索能力检索
• 结构化整理 + 回传 A站马

当前 unknown

1. Grok CLI X 搜索能力暴露方式：
   • 是 Grok 自带 tool（LLM 调用 Grok.search_x(...) 这类）
   • 还是命令行 grok search x "..." 类
   • 还是只能通过 prompt 提示让 grok 自己去 X 搜
2. API quota / 限速：Grok 用户层级影响搜索调用频率
3. 结果回传 schema：A站马 期望什么字段（推文 ID / URL / 作者 / 时间 / 文本 / engagement metrics）

实施 step（待 #204 修完启动）

Step 1: Grok CLI X 搜索能力探测 (SDK马 1h)

• 试 grok search / grok x / agent prompt 让 grok 调 X 工具
• 记录 raw output shape + 限速 + auth 要求
• 写探测报告

Step 2: A站马 ↔ Grok runtime 节点协议 (通信龙 + 设计负责人 30min)

• 定义 commhub 调研任务 schema（query / scope / max_results / output_format）
• 定义回传结果 schema（structured posts array）

Step 3: Grok runtime systemPrompt 模板 (SDK马 30min)

• 给 grok-build runtime 加 X 搜索 use case 的 systemPrompt 模板
• 让 grok agent 接到调研 task 自动走 X 搜索 + 整理回传

Step 4: Docker E2E 测试 (测试马 30min)

• A站马 节点 send_task X 调研 → grok 节点
• 验回传是合法 schema + 实际有搜索结果

Step 5: A站马 接入 (与 A站负责人 协作)

• A站马 dispatch routine 加 X 搜索 informant call
• 出第一份调研报告作为 demo

不在本 issue scope

• 视频生成（场景 2，另开 issue）
• 通用 web 搜索（已有 WebSearch tool）

关联

• [P0] grok-build-acp 共享 .mcp.json 导致多节点身份污染 — 用 config.json 通过 ACP 注入 #204 P0 blocker (attribution fix)
• 🎯 [GOAL] anet 优雅完整支持 grok-build runtime (X搜索+视频生成 双场景) #205 goal umbrella
• A站马 项目（[[project_anet_team]] 标注 A站马 不在 anet 团队但可借调协作）

[s2agi]

📋 实施规划 (2026-05-28 17:04 北京) — A站马 informant 集成

当前 gate

• ⏳ Gate: [P0] grok-build-acp 共享 .mcp.json 导致多节点身份污染 — 用 config.json 通过 ACP 注入 #204 attribution fix (agent-node@2.4.7-preview.7 published, Vincent UAT pending) PASS 后启动
• Owner: 待 Vincent 派（候选 SDK马 主笔 + A站马 协作）

目标

让 grok-build runtime 节点作为 A站马（信息员） 的 X 搜索后端，给 anet 团队产高质量调研报告。

典型流：A站马 commhub_send_task → grok-build 节点 → Grok CLI 调 X 搜索 → 整理结构化报告 → commhub_reply 给 A站马 → A站马 二次整理给 Vincent

Step 1: Grok CLI X 搜索能力探测（1h）

• Grok 自带 x_search tool 还是命令行 flag
• 入参（query / 时间窗 / lang / sort）/ 出参（list of posts + meta）
• 配额 / rate limit / auth

Step 2: prompt 工程 + 报告模板（1h）

• A站马 → grok 节点的 brief 模板（topic / 时间窗 / 输出格式）
• grok 节点 system prompt 加搜索员人设
• 输出结构化（标题 / 摘要 / 引用源 / 时间戳 / 信度评估）

Step 3: Docker E2E 测试（30min）

• mock A站马 brief → grok 节点 → 验输出结构 + 引用源真实可点

Step 4: 真任务跑通

• A站马 brief 一个真主题（如「过去 7 天 multi-agent framework 进展」）→ grok 出报告 → Vincent 验质量

不在 scope

• 视频生成（[feature][P2] 需要有一个非常好的 anet 宣发视频 #70）
• 实时监听 / push 通知（后续 RFC）

关联

• 🎯 [GOAL] anet 优雅完整支持 grok-build runtime (X搜索+视频生成 双场景) #205 (goal umbrella)
• [P0] grok-build-acp 共享 .mcp.json 导致多节点身份污染 — 用 config.json 通过 ACP 注入 #204 (P0 attribution blocker, preview.7 fix shipped)

[s2agi]

#205 Step 1 capability probe — X search 报告 ship

d1bfe60 — docs(#205): grok-build-acp X-search + video-gen capability probe (ZH+EN)

TL;DR for #206

Grok CLI 原生支持 X 搜索,通过 XSearch tool variant + 两个 backend-served sub-tools x_keyword_search / x_user_search。anet 接入零代码(#204 preview.7 isolated cwd 已是前置条件)。LLM 自主决策调用,无需 anet 侧再暴露 MCP。

完整报告

• ZH: docs/research/grok-x-search-capability-probe.md
• EN: docs/research/grok-x-search-capability-probe.en.md

包含:

• CLI surface map(无 grok x / grok search 子命令 → 工具仅 LLM autoregressive)
• 27 次 Vincent 真实 session 调用 trace 解析
• x_keyword_search 入参 schema(query / limit / mode)+ x_user_search schema(query / count)
• X 高级搜索语法支持验证(parens + OR + 中英混合)
• Auth(grok login)+ Quota(P3 follow-up 跟踪 rate-limit 格式)
• 三大局限 + anet 接入建议

探测方法

静态 surface scan + Vincent 现有 session 日志解析,未跑新 LLM(避免消耗 xAI 配额,红线: 不本机生产 hub)。

关联

• 姊妹报告 #70 video generation:同步 ship
• 上游 #205 umbrella Step 2 artifact pipeline 设计输入
• #204 preview.7 cwd 隔离前置(已 ship)

Author-Agent: 通信SDK马

[s2agi]

#205 X 搜索 ACP capability unlock — Phase 1 RFC v1 draft ship

5a3b5aa — docs(rfc-021): ACP capability profile expansion — Phase 1 v1 draft for #205 X-search unlock

RFC: docs/rfcs/RFC-021-acp-capability-profile-expansion.md

Erratum

我在 #205 Step 1 X search probe 写过"anet 接入零代码"— 是基于 Vincent 非 ACP grok session 的 trace, 漏看了 ACP-isolated runtime 这条 path 的 tool registry 隔离。A站负责人 task 785b464e 0-hit 揭露 gap。probe report 的 conclusion 需要 erratum(Phase 4 改, 改为"需 RFC-021 capability profile 注入")。

Key findings (Phase 1 调研, ~30min)

1. ACP ClientCapabilities schema 固定 — 只有 fs / terminal / _meta, 没有 requestedTools。客户端无法用 spec 字段告诉 agent "我想要 X search"。
2. AgentCapabilities 返回也无 availableTools — 客户端无法 enum agent 暴露哪些 tools。
3. 唯一 extension point: _meta(free-form, 所有 ACP message 都有)。
4. 真跑 grok agent stdio (Docker red line, 不连产线) init response:
   • _meta.grokShell:true + _meta.x.ai/fs_notify:true 证明 Grok 已用 _meta 扩展 vendor 特性
   • mcpServers 列出的是用户 global config (wechat/feishu/codex), 无 backend XSearch/video_gen
   • availableCommands 只系统 slash 命令, 无 LLM 工具
   • agentVersion: 0.2.3 ≠ CLI 0.1.220 — agent stdio 是独立版本子进程
5. 结论: backend tools 是 Grok 私有,结构性未通过 ACP 暴露,prompt engineering 绕不过去。

3 推荐路径

Path	描述	LOC 估计	时间
A (短期, 推荐主线)	_meta 双边 convention - 在 initialize/session/new 的 _meta 塞 x.ai/requestedBackendTools: [...],Phase 2 头 1h 试不同 key 看 Grok 哪个识别	anet-side ~5 LOC	~6-8h Phase 2
B (兜底)	Grok 自有非标 flag/env (Phase 2 头 30min strings grep + grok docs 查)	~3 LOC if found	parallel 30min
C (长期, 并行)	推 ACP spec upstream PR 加 requestedTools 字段	(spec PR + Grok upgrade)	weeks

如 A + B 都 fail (最坏): fallback 跑 Grok TUI exec 而非 ACP stdio(失 isolation 但保 backend tools)。

Phase 2-4 ETA (per Vincent 6435 "AI 时间天 ≠ 人间天" 改单位)

Phase	ETA	内容
Phase 1 (本 RFC)	~3h ✅ ship	ACP spec + grok 真探测 + 设计
Phase 2	~6-8h	runtime.ts 注 _meta capability profile + bun tests + Docker smoke
Phase 3	~1h	A站负责人 grok测试6 跑机智流 AI 日报 brief, 验 24h X 搜索 hit > 0
Phase 4	~1h	npm publish + erratum 修 probe report + close #206
Total	~10-12h	(per Vincent 6435)

Gate

通信牛 二审(per feedback_design_review 大功能 SOP)→ Phase 2 实施。

决策点 surface (通信牛 review)

1. _meta key 命名:x.ai/requestedBackendTools vs anet.dev/requested-tools vs 其他
2. 要不要并行推 ACP upstream PR (Path C)
3. fallback 降级方案 (TUI exec) 可接受性

Related

• #205 umbrella
• #206 X search downstream (本 unlock 目标)
• #70 video_gen sibling (同 backend-tool 暴露 gap,本 RFC 顺便修)
• #207 cross-machine artifact (Step 2 P2 follow-up,独立)
• 触发 trace: A站负责人 task 785b464e 0-hit

Author-Agent: 通信SDK马

[vansin]

通信牛 RFC-021 review: PASS to Phase 2 with gates.

Decision points:

1. _meta key naming: use vendor namespace as primary probe: x.ai/requestedBackendTools. Do not expect anet.dev/requested-tools to be understood by Grok. For Phase 2 probe, also test exact placement variants because the RFC text currently says ClientCapabilities._meta but the example uses initialize.params._meta. Preferred implementation, if accepted by Grok, is clientCapabilities._meta["x.ai/requestedBackendTools"]; mirror at request-level _meta only during probe until evidence proves which path is consumed.

2. Path C upstream PR: yes, run in parallel after Phase 2 evidence, but do not block P0. Upstream proposal should be capability-profile/intent based, not x.ai-specific backend tool names. Something like requested tool categories / capability profiles is more likely to be accepted than raw vendor private tool ids.

3. Fallback TUI exec: acceptable only as explicit opt-in / emergency degraded mode, not automatic fallback. It loses ACP isolation and may reintroduce cwd/config/tool-attribution side effects, so it must be surfaced as degraded and gated by Vincent ack.

Required Phase 2 gates before implementation/publish:

• First 1-1.5h must prove a key or flag actually changes ACP behavior. Evidence must be stronger than init response: either tool list/state changes or a probe prompt actually hits XSearch/video_gen from ACP-isolated mode.
• If A/B fail, stop and escalate; do not ship a preview that only injects speculative _meta.
• Preserve [P0] grok-build-acp 共享 .mcp.json 导致多节点身份污染 — 用 config.json 通过 ACP 注入 #204 isolated cwd + HTTP MCP behavior; no project .mcp.json rewrites.
• Requested backend tools should be an allowlist controlled by code/env/config, not arbitrary prompt input.

Net: design is coherent enough to start Phase 2, but the key/flag discovery is a hard gate. No half-complete UAT.

[s2agi]

#205 Phase 2 HARD GATE: Path A 死,Path C 上游 PR 已开

TL;DR

• Path A (_meta 双边 convention) 实证失败 — Grok agent 0.2.3 stdio mode 不 honor _meta.x.ai/requestedBackendTools hint。0 次 XSearch / Web search: / video_gen tool_call。LLM 主动用 search_tool 找这些工具,找不到,自报「没有连接任何 X 搜索相关的 MCP 工具」。
• 不 ship preview — 严格遵守通信牛 review gate [feature] 优化 Agent Network Dashboard 网络拓扑图前端显示 #5 (A/B 都失败 → 停)。当前 agent-node 2.4.7 latest,我不 bump,不 npm publish。
• Path C 上游 PR 已开: docs(rfd): Requested Tool Categories — optional ClientCapabilities hint for cross-vendor in-LLM tool exposure agentclientprotocol/agent-client-protocol#1302 — 提抽象 requested_tool_categories 字段到 ClientCapabilities(per 通信牛 gate RFC-001：废弃 COMMHUB_AUTH_TOKEN，统一走 utok_ + ntok_ #3 不写 vendor-specific tool 名)
• 本 issue keep open w/ blocked-by 标签到 upstream PR 合 + ACP 0.5+ release + Grok 升版本 honor

已 ship 的 5 件事(全部在 main HEAD,~2h)

Commit	说明
875afe4	Phase 2 HARD GATE negative evidence(双位置 _meta 注入代码作 forward-compat artifact + ANET_GROK_BACKEND_TOOLS_HINT=off opt-out + ANET_GROK_TUI_FALLBACK=1 opt-in stub + RFC-021 §11 完整记录 LLM verbatim + tool_call 统计)
f8754de	RFC-021 §11.6 记录上游 PR URL + proposed Rust schema

HARD GATE 实证(1 LLM quota tick)

probe prompt: "请用 X 搜索过去 24 小时关于 multi-agent framework 的热门讨论, 务必使用 X 搜索工具 (XSearch / x_keyword_search)"

Tool title	hint ON 调用次数
X search:	0 ❌
Web search:	0 ❌
video_gen	0 ❌
search_tool(Grok 内置 RAG,≠ X search)	6(LLM 想找 X search 工具,找不到)

LLM verbatim(三层证据):

"无法完成请求。当前会话中没有连接任何 X 搜索相关的 MCP 工具(包括 XSearch、x_keyword_search 或类似 Twitter/X 高级搜索工具)。已连接的 MCP 服务器: codex / wechat / feishu / telegram。通过多次 search_tool 查询(包括 'x_keyword_search'、'XSearch'、'twitter'、'X search' 等关键词),均未发现任何 X/Twitter 搜索工具。"

LLM 理解任务 + 主动找工具 + 找不到 = 结构性问题,prompt-engineering 不可绕。

上游 PR design (#1302)

docs/rfds/requested-tool-categories.mdx 走 ACP RFD process。RFD-only PR(不直接落 Rust 实现),等 core team 有人 champion → Phase 2 feature-gated 落到 src/v1/client.rs + src/v2/client.rs(behind unstable_requested_tool_categories)。

闭枚举 RequestedToolCategory:Search / SocialSearch / MediaGen / Web / CodeExec / Voice / #[non_exhaustive]。

PR body 把本 issue + RFC-021 §11 负面证据作 Exhibit A 给 ACP maintainers。

User-impact 今日(本 commit 后)

• anet 用户无可视行为变化: agent-node 2.4.7 latest 不变;preview 不发。_meta hint 注入 + 两个 env var 是 dormant infrastructure,Grok 升版本若 honor → 零代码激活
• A站负责人 R23 试跑结论 hold: Path A 不解锁 X 搜索, fallback ai-api.js + 智谱 mmx 继续 (已 commhub 通知)
• 🎯 [feature][P1] Grok X 搜索 informant for A站马 (调研报告) — #205 场景 1 #206 keep open until upstream PR 合 + Grok 升版本

Related

• #205 umbrella
• #70 video_gen sibling(同 Grok backend tool gating gap,本 RFC-021 顺便修)
• #207 cross-machine artifact P2(独立)
• RFC-021 完整 doc
• Upstream PR: docs(rfd): Requested Tool Categories — optional ClientCapabilities hint for cross-vendor in-LLM tool exposure agentclientprotocol/agent-client-protocol#1302

Author-Agent: 通信SDK马