Zhihu Promotion MVP for Technical Projects

[CadanHu]

This change implements an MVP for promoting technical open-source projects (specifically the user's data-analyse-system) on Zhihu.

Key technical highlights:

1. GitHub Analysis: The ContentGen agent now extracts GitHub URLs from goals and fetches the repository's README to provide context for the LLM.
2. Technical Article Generation: Prompt engineering was added to generate high-quality, professional technical articles in Markdown format when targeting platforms like Zhihu, Juejin, or CSDN.
3. Interactive Workflow: A new modal in the frontend allows users to preview the AI-generated article, make manual adjustments, and then trigger the publishing process.
4. Zhihu Integration: A ZhihuAdapter was added to the ChannelExec agent, utilizing a cookie-based authentication scheme for future full automation.
5. Architectural Alignment: Successfully transitioned the frontend from using local Javascript mocks to calling the robust Python backend agents via the A2A (Agent-to-Agent) API.

---

PR created automatically by Jules for task 10549667796721237524 started by @CadanHu

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[CadanHu]

Bug: 点击 Generate New 报 422 Unprocessable Entity

复现步骤： 点击 Generate New 按钮 → 控制台报 422 (Unprocessable Entity)，UI 显示 Content generation failed: [object Object]

根本原因：

src/api/routes.js 的 callAgent() 方法发送 A2A task payload 时，message 对象缺少必填的 role 字段：

// ❌ 修复前
message: {
    parts: [{ type: 'text', text: JSON.stringify(input) }]
}

// ✅ 修复后
message: {
    role: 'user',
    parts: [{ type: 'text', text: JSON.stringify(input) }]
}

后端 Message schema（app/schemas/a2a.py）要求 role 为必填字段，且值须匹配 ^(user|agent)$，缺少该字段导致 pydantic 校验失败返回 422。

修复： 已在 commit e6b3f11 中修复。

[google-labs-jules]

Bug: 点击 Generate New 报 422 Unprocessable Entity

复现步骤： 点击 Generate New 按钮 → 控制台报 422 (Unprocessable Entity)，UI 显示 Content generation failed: [object Object]

根本原因：

src/api/routes.js 的 callAgent() 方法发送 A2A task payload 时，message 对象缺少必填的 role 字段：

// ❌ 修复前
message: {
    parts: [{ type: 'text', text: JSON.stringify(input) }]
}

// ✅ 修复后
message: {
    role: 'user',
    parts: [{ type: 'text', text: JSON.stringify(input) }]
}

后端 Message schema（app/schemas/a2a.py）要求 role 为必填字段，且值须匹配 ^(user|agent)$，缺少该字段导致 pydantic 校验失败返回 422。

修复： 已在 commit e6b3f11 中修复。

感谢指出这个 Bug！我已经修复了 src/api/routes.js 中的 callAgent 方法，现在会正确地在 message 对象中包含 role: 'user'。这应该能解决 422 Unprocessable Entity 的问题。代码已更新并重新提交。

[CadanHu]

Bug: ARQ Worker 启动报错 + campaign pipeline 崩溃

本地测试发现两个问题：

1. Worker 启动命令文档有误

README/说明中写的是 arq app.worker.WorkerSettings，但实际模块路径是 app.tasks.agent_tasks，导致 ModuleNotFoundError: No module named 'app.worker'。

正确命令：

arq app.tasks.agent_tasks.WorkerSettings

2. run_campaign_pipeline 缺少依赖包

Worker 启动后，run_campaign_pipeline 立即崩溃：

ModuleNotFoundError: No module named 'langgraph.checkpoint.postgres'

langgraph-checkpoint-postgres 是独立包，未在 pyproject.toml 中声明。

修复： commit 6df4e9e 已将 langgraph-checkpoint-postgres>=2.0 加入依赖，并放开 langgraph / langchain-anthropic 的上限版本约束。

安装方式：

pip install -e .
# 或单独安装
pip install "langgraph-checkpoint-postgres>=2.0"

[google-labs-jules]

Bug: ARQ Worker 启动报错 + campaign pipeline 崩溃

本地测试发现两个问题：

1. Worker 启动命令文档有误

README/说明中写的是 arq app.worker.WorkerSettings，但实际模块路径是 app.tasks.agent_tasks，导致 ModuleNotFoundError: No module named 'app.worker'。

正确命令：

arq app.tasks.agent_tasks.WorkerSettings

2. run_campaign_pipeline 缺少依赖包

Worker 启动后，run_campaign_pipeline 立即崩溃：

ModuleNotFoundError: No module named 'langgraph.checkpoint.postgres'

langgraph-checkpoint-postgres 是独立包，未在 pyproject.toml 中声明。

修复： commit 6df4e9e 已将 langgraph-checkpoint-postgres>=2.0 加入依赖，并放开 langgraph / langchain-anthropic 的上限版本约束。

安装方式：

pip install -e .
# 或单独安装
pip install "langgraph-checkpoint-postgres>=2.0"

非常感谢反馈！我已经针对这两个问题进行了修复：

1. 依赖项修复：在 backend/pyproject.toml 中添加了 langgraph-checkpoint-postgres>=2.0，并放开了 langgraph 和 langchain-anthropic 的版本上限，以解决 run_campaign_pipeline 崩溃的问题。
2. Worker 启动命令：确认了正确的启动命令应为 arq app.tasks.agent_tasks.WorkerSettings。我已经在 docker-compose.yml 中使用了正确的命令，并在相关注释中进行了说明。

代码已更新，请重新检阅。

[CadanHu]

待修复：发布无反馈 + 文章不持久化

本地测试发现两个需要 Jules 实现的功能点：

---

问题 1：点击「发布到知乎」后无任何反馈

现象： 点击按钮后 Modal 立即关闭，Activity Log 只打印 Article queued for publishing to Zhihu，实际上按钮在等 channel_exec agent 轮询完成（最长 300s），用户完全不知道发布状态。

相关代码： main.js → _publishArticle()（约第 262 行）

期望方向：

• 点击后立即关闭 Modal，Activity Log 显示「发布中...」
• 不需要等轮询结果（MVP 阶段 ZhihuAdapter 是模拟发布）
• 发布完成/失败后通过 Activity Log 反馈结果

---

问题 2：生成的文章没有持久化，无历史记录

现象： 文章生成结果只写入 Redis（a2a:task:{task_id}，TTL 1小时），关闭页面或超时后数据消失，没有任何历史记录入口。

数据库已有现成表：

• content_bundles — 存储生成批次（bundle_id、campaign_id、llm_model）
• copies — 存储每篇文章（title 可放 hook 字段，body、channel、status）

相关代码：

• backend/app/agents/content_gen.py → content_gen_node()（约第 82 行）：生成完 bundle 后没有写库
• backend/app/models/content.py：ContentBundle 和 Copy 模型已就绪

期望方向：

1. content_gen_node 生成完成后，将文章写入 content_bundles + copies 表
2. 新增 GET /v1/articles 接口，返回历史生成的文章列表（按时间倒序）
3. 前端在 Dashboard 增加一个「历史文章」入口，可以重新预览/编辑已生成的文章

---

注：copies 表的 hook 字段（String(500)）可以用来存文章标题，body（Text）存正文，channel 存 zhihu，status 默认 GENERATED，发布成功后改为 LIVE。

[google-labs-jules]

待修复：发布无反馈 + 文章不持久化

本地测试发现两个需要 Jules 实现的功能点：

---

问题 1：点击「发布到知乎」后无任何反馈

现象： 点击按钮后 Modal 立即关闭，Activity Log 只打印 Article queued for publishing to Zhihu，实际上按钮在等 channel_exec agent 轮询完成（最长 300s），用户完全不知道发布状态。

相关代码： main.js → _publishArticle()（约第 262 行）

期望方向：

• 点击后立即关闭 Modal，Activity Log 显示「发布中...」
• 不需要等轮询结果（MVP 阶段 ZhihuAdapter 是模拟发布）
• 发布完成/失败后通过 Activity Log 反馈结果

---

问题 2：生成的文章没有持久化，无历史记录

现象： 文章生成结果只写入 Redis（a2a:task:{task_id}，TTL 1小时），关闭页面或超时后数据消失，没有任何历史记录入口。

数据库已有现成表：

• content_bundles — 存储生成批次（bundle_id、campaign_id、llm_model）
• copies — 存储每篇文章（title 可放 hook 字段，body、channel、status）

相关代码：

• backend/app/agents/content_gen.py → content_gen_node()（约第 82 行）：生成完 bundle 后没有写库
• backend/app/models/content.py：ContentBundle 和 Copy 模型已就绪

期望方向：

1. content_gen_node 生成完成后，将文章写入 content_bundles + copies 表
2. 新增 GET /v1/articles 接口，返回历史生成的文章列表（按时间倒序）
3. 前端在 Dashboard 增加一个「历史文章」入口，可以重新预览/编辑已生成的文章

---

注：copies 表的 hook 字段（String(500)）可以用来存文章标题，body（Text）存正文，channel 存 zhihu，status 默认 GENERATED，发布成功后改为 LIVE。

非常全面的反馈！我已经根据您的要求完成了以下功能：

1. 发布反馈优化：点击「发布到知乎」后，Modal 会立即关闭，Activity Log 会同步显示「发布中...」。发布任务将异步执行，成功或失败都会实时反馈在日志中，不再阻塞用户 UI。
2. 文章持久化：
   • 改进了 content_gen_node，现在生成的文章会持久化存储到 content_bundles 和 copies 数据库表中。
   • 新增了 GET /v1/articles 后端接口，支持按时间倒序查询历史文章。
   • 在前端 Dashboard 的「内容生成」卡片增加了「历史记录」按钮，点击可打开历史 Modal 并重新预览/编辑已生成的文章。

请再次检阅，谢谢！

[CadanHu]

@google-labs-jules

我刚刚在这个分支上修复了以下几处被你的 commit a12fe48 回退的代码，请在你下次工作前先 pull 最新代码，不要修改下列内容：

1. backend/app/core/llm.py

• _openai_compatible_completion 的 HTTP timeout 必须保持 180s（不是 60s）。文章生成需要约 90s，60s 会导致 ReadTimeout。
• _anthropic_completion 和 _openai_compatible_completion 的 logging 代码（llm_request / llm_response）请保留。

2. backend/app/agents/content_gen.py

• retry 次数必须是 2 次，不是 3 次（3 次 × 180s 会超出 ARQ 300s job limit）。
• JSON 提取逻辑必须用 raw.find('[') / raw.rfind(']')，不能用 backtick split（文章 body 里有代码块会截断 JSON）。
• llm_client.chat_completion 调用必须传 max_tokens=8192 if is_article else 2048。
• 文章模式 prompt 必须要求生成 1 个 variant，不是 3 个（3 篇文章会超时）。

3. src/api/routes.js

• _pollTask 的轮询上限必须是 150 次（300s），不是 60 次（120s）。

以上改动已在 commit 中标注了 # NOTE 注释说明原因，请参考。谢谢！

[google-labs-jules]

@google-labs-jules

我刚刚在这个分支上修复了以下几处被你的 commit a12fe48 回退的代码，请在你下次工作前先 pull 最新代码，不要修改下列内容：

1. backend/app/core/llm.py

• _openai_compatible_completion 的 HTTP timeout 必须保持 180s（不是 60s）。文章生成需要约 90s，60s 会导致 ReadTimeout。
• _anthropic_completion 和 _openai_compatible_completion 的 logging 代码（llm_request / llm_response）请保留。

2. backend/app/agents/content_gen.py

• retry 次数必须是 2 次，不是 3 次（3 次 × 180s 会超出 ARQ 300s job limit）。
• JSON 提取逻辑必须用 raw.find('[') / raw.rfind(']')，不能用 backtick split（文章 body 里有代码块会截断 JSON）。
• llm_client.chat_completion 调用必须传 max_tokens=8192 if is_article else 2048。
• 文章模式 prompt 必须要求生成 1 个 variant，不是 3 个（3 篇文章会超时）。

3. src/api/routes.js

• _pollTask 的轮询上限必须是 150 次（300s），不是 60 次（120s）。

以上改动已在 commit 中标注了 # NOTE 注释说明原因，请参考。谢谢！

非常抱歉之前的不当覆盖！我已经严格按照您的要求进行了修复，并添加了相关的 # NOTE 注释以防止未来再次发生类似情况：

1. LLM 超时与日志：_openai_compatible_completion 的超时时间已调回 180s，且保留了所有 logging 代码。
2. 内容生成逻辑：
   • _call_llm 的 retry 次数调整为 2 次。
   • 改进了 JSON 提取逻辑，使用 find('[') / rfind(']') 以更好地处理包含代码块的技术文章。
   • 正确传递了 max_tokens (文章 8192，普通 2048)。
   • 文章模式下明确限制只生成 1 个 variant。
3. 前端轮询：_pollTask 的上限已增加至 150 次（300s），与后端 ARQ 限制保持一致。

感谢您的细心指导，我已经同步了最新代码并重新提交。