一条 Prompt 为什么做不好专业 Agent？我把软著 Agent 拆开给你看
开头
很多人第一次写 Skill，思路都是：
你是一名软件著作权专家。
请读取我的项目，
分析项目功能，
然后生成软件说明书、源码文档和申请材料。
要求专业、准确、完整。
看起来没问题。
但真正把它交给一个完全不懂软著的小白，很快就会出现几个问题：
AI 不知道哪些信息可以从代码判断，哪些必须问用户；不知道生成的功能是否真的存在；不知道不同材料之间有没有事实冲突；更不知道什么时候应该停下来要求人工确认。
这也是我在做 Copyright Forge Skill 时越来越明确的一件事：
专业 Agent 的核心不是 Prompt，而是 Workflow + Evidence + State + Validation。
目前仓库本身已经不是简单的一份提示词，而是包含 skills/copyright-forge、tests、docs、示例项目以及 CI 工作流等结构。README 对它的定位也很明确：从真实软件项目生成“可追溯、可检查、可继续修改”的软著材料。([GitHub][1])
第一层：先取证，而不是先生成
Copyright Forge 最值得拆出来讲的一个设计，其实是：
项目
↓
读取 README
↓
读取配置文件
↓
扫描目录
↓
分析源码
↓
建立功能证据
↓
形成事实源
↓
生成材料
而不是：
项目名称
↓
LLM 猜功能
↓
生成材料
README 甚至明确要求 Agent：
不得虚构功能、源码、截图、权属、开发关系、发表事实或日期。
同时说明书里的功能必须能够找到项目证据。([GitHub][1])
这实际上对应了 Agent 工程里非常重要的概念：
Grounding
也就是把模型生成建立在真实证据上。
例如扫描一个后台项目时：
backend/
controller/
service/
model/
frontend/
src/
pages/
README.md
docker-compose.yml
Agent 可以从代码确认：
features:
- name: 用户管理
evidence:
- backend/controller/user.go
- frontend/src/pages/user/
- name: Redis 缓存
evidence:
- docker-compose.yml
- backend/cache/redis.go
这时候“用户管理”才从一句 AI 推测变成了：
Claim → Evidence
第二层：把“可推断事实”和“不可推断事实”分开
这是专业 Agent 和普通 Prompt 最大的区别之一。
比如：
软件名称：？
开发完成日期：？
是否发表：？
著作权人：？
合作开发还是独立开发：？
这些东西 AI 不应该从 GitHub 猜。
但是：
使用什么语言？
有没有用户管理？
有没有 Redis？
数据库是什么？
有哪些页面？
有哪些 API？
通常可以从代码分析。
所以 Agent 最合理的逻辑应该是：
facts = analyze_project()
unknowns = []
if not facts.get("copyright_owner"):
unknowns.append("著作权人")
if not facts.get("completion_date"):
unknowns.append("开发完成日期")
if not facts.get("development_relationship"):
unknowns.append("开发关系")
ask_user(unknowns)
而不是：
ask_user_everything()
Copyright Forge 的 README 也采用了这种思路：先自行分析项目、文档、配置和代码，只把无法从项目判断的权属、开发关系、真实日期和公开使用事实集中向用户确认。([GitHub][1])
这会直接改变小白用户的体验。
用户只需要说：
帮我给这个项目做一套软著材料。
剩下的流程由 Agent 自己推进。
第三层：建立 Single Source of Truth
Agent 长任务有一个非常典型的问题：
第一份文档：
软件名称：FlowTask
版本：V1.0
第二份文档：
软件名称：FlowTask Pro
版本：1.0.0
第三份：
开发完成日期：2026-08-20
第四份却写成：
2026-08-18
单篇文章都没错。
组合起来却错了。
所以专业工作流应该先形成统一事实源：
software:
name: FlowTask
version: V1.0
owner:
name: 王仕宇
development:
type: independent
completion_date: 2026-08-20
features:
- task_management
- workflow
- notification
后面的所有文档：
申请信息
说明书
源码材料
截图说明
全部读取同一份数据。
这其实就是软件工程里的：
Single Source of Truth
第四层：生成和审核必须分离
很多 AI 工作流最大的问题是：
Agent 生成
↓
Agent 自己说“检查完成”
这其实非常危险。
更合理的是：
Evidence Builder
↓
Fact Builder
↓
Document Generator
↓
Independent Reviewer
↓
Final Output
Reviewer 要重新检查：
功能有没有代码证据？
名称是否统一？
版本是否统一？
日期是否一致？
有没有敏感信息？
有没有虚构事实？
源码是否来自真实项目？
甚至可以写成机器规则：
def validate(doc, facts):
assert doc.software_name == facts.software_name
assert doc.version == facts.version
for feature in doc.features:
assert feature.evidence_count > 0
这时候 Agent 才开始具有真正的工程可靠性。
第五层：Skill 的价值是“把专家流程产品化”
因此我现在越来越倾向于把 Skill 理解成：
Skill
=
Prompt
+ Workflow
+ Tools
+ Evidence
+ State
+ Validation
+ Output Contract
而不是：
Skill = 一个很长的 Prompt
这也是 Copyright Forge 这个项目最值得开发者借鉴的地方。
它表面上是在做软著。
实际上它探索的是：
怎么把一个专业人士的工作流程，压缩成一个普通人只说一句话就可以启动的 Agent Workflow。
总结
如果你正在开发 Agent、MCP 或 Skill，我建议重点检查下面 5 件事：
① 模型生成之前有没有真实证据？
② 哪些事实可以推断，哪些必须询问？
③ 有没有统一事实源？
④ 生成和审核有没有分离？
⑤ 最终结果是否可以追溯？
这五个问题解决之后，你做出来的才更接近一个专业工具。
否则很可能只是：
一个套着 Agent 外壳的超级 Prompt。
配图设计
建议画面标题：
《Prompt ≠ Agent：专业 Skill 的 5 层架构》
两个二次元程序员对话：
左：
“我写一个 5000 字 Prompt，不就能做专业 Agent 了吗？”
右：
“真正难的是证据、事实源、状态、审核和工作流。”
中间画：
真实项目
↓
Evidence
↓
Facts
↓
Workflow
↓
Generate
↓
Review
底部：
Copyright Forge Skill · 王仕宇 / JavaPub
浙公网安备 33010602011771号