搭Coze工作流搭到第五六次的时候我卡在了一个特别基础的问题上用户往对话框里丢了一个链接让智能体“读一下这篇文章帮我总结核心观点”。结果我搭好的智能体压根不理这个链接直接编了一段看起来很像回事的“读后感”。后来我才反应过来大模型本身不会主动去打开链接它只能依赖你喂给它的文本。想让智能体真正“读懂”一篇文章就得在工作流里给它补一个“代读”环节。最顺手的方案就是代码节点。这篇文章就从这个初实践出发聊聊怎么在Coze里用代码节点配合AI编程自动把链接对应的文章标题、正文提取出来再交给大模型去做摘要和信息提取。整个过程不需要你有很强的编程基础会复制代码、会照着界面点基本就能跑通。1. 什么场景下你的智能体需要“真正读链接”1.1 别指望大模型凭空看见一个网页我刚接触Coze的时候有个错觉智能体连上网了它是不是就能自己打开任何网页试了几次才发现模型和“网页浏览器”是两回事。你给它一个URL它并不知道那个URL背后是什么内容除非你在工作流里显式地加入了网络搜索或网页解析类的节点否则它就只能靠训练时见过的东西去猜。最典型的表现就是你问它“这篇链接讲了什么”它会煞有介事地回答但内容完全是基于标题的合理想象甚至可能张冠李戴。这不是模型笨而是它的输入通道里根本没有这个网页。理解了这个原理你就能明白一件事在Coze里做文章内容处理本质是“先抓取、再理解”。抓取这一步交给代码节点来做最直接也最可控。1.2 代码节点在这一环里到底干了什么代码节点在整条工作流里的角色有点像帮大模型跑腿的助理。它接收上游传下来的参数——大部分场景里就是这个文章链接然后替你发出网络请求拿到HTML源码再从一堆标签里把标题和正文抠出来清洗成干干净净的文本最后把这些文本作为结构化字段返回给下游节点。为什么要专门用代码节点而不是让大模型节点直接处理链接因为模型节点能处理的是文本和结构化数据它没有去网络上“取货”的能力。而代码节点可以。它能发送HTTP请求、解析HTML、做字符串处理甚至能根据返回内容决定下一步怎么走。换句话说只要你想让智能体完成“读取某篇文章并总结”“提取文章里的价格和型号”“把一段网页内容转成固定表格格式”这类需求代码节点几乎都是绕不开的中间环节。适合参考这篇文章的读者大概率是已经试过Coze基础搭建、知道节点之间怎么连线但还没认真碰过代码节点的朋友。你不需要会写代码但需要有一点点耐心去理解“输入-处理-输出”的逻辑。后面所有内容都按这个逻辑展开。2. 动手前先搞清楚代码节点的“脾气”2.1 入口函数、入参和返回值的约定在实际写代码之前我强烈建议你先在Coze画布里放一个代码节点点进去看一下它的编辑界面。因为代码节点是有固定“契约”的跟你在本地写Python脚本完全不一样。本地脚本你可以随便定义入口、随意打印代码节点则要求你实现一个明确的入口函数把你要处理的入参写在函数的参数列表里最后通过return返回一个JSON对象。以Python为例一个最基本的代码节点大概长这样def main(url: str): # 你的业务逻辑 return { title: 示例标题, content: 正文内容 }这里有个特别容易忽略的点main函数的参数名和参数类型不是你自己拍脑袋定的而是要和节点配置里的输入参数对上。你在代码节点右上角或者左侧配置区添加一个名为url、类型为String的入参代码里才能有一个叫url的变量。如果你在界面里叫article_url代码里写的却是url运行的时候就会报错说找不到这个参数。返回值也一样。return出来的字段名就是下游节点引用时看到的字段名。文章里我会用code、title、content、error这些固定字段。后面在LLM节点里你就可以直接引用fetch_result.content或者类似的变量路径。这些字段名务必前后保持一致这是新手最容易踩进去的第一个坑。2.2 用AI帮你写代码的提示词模板这里就是标题里“AI编程”真正发力的地方。抓取网页这种代码逻辑高度模板化你根本不用自己从零写直接让大模型生成就行。但有个前提你在给AI的提示词里要把上面说的“契约”讲清楚。否则AI给你生成一个标准Python脚本里面又是input()又是print()到了代码节点里根本跑不了。我试过一版效果不错的提示词模板你直接复制过去改需求就行我在Coze工作流里使用Python代码节点。 节点要求必须实现一个 main() 函数作为入口入参是一个名为 url 的字符串。 我需要通过 url 抓取网页文章内容解析出标题和正文。 请给我一段完整的代码要求 1. 使用 requests 发送请求设置 User-Agent 和超时时间 2. 处理编码避免中文乱码 3. 去掉 script、style、noscript 等无关注签 4. 正文中连续换行压缩成不超过两个换行 5. 最终返回一个 JSON 对象包含 code、title、content、length 四个字段 6. 所有请求异常都要捕获不要把异常抛出而是通过 code 和 error 字段返回错误信息 请只输出代码不要解释。AI一般会根据这个模板生成一段能直接粘贴的代码。如果用AI工具它懂“Coze代码节点”这个场景的概率很大就算没懂你只要把上面那段“节点要求”贴进去也能让它生成符合规范的代码。这和纯编程不同你不需要自己背requests的API只需要能描述清楚“输入是什么、输出要什么、边界条件有哪些”。2.3 遇事不决先打印不要盲改代码代码节点里调试和本地有点不一样。本地你随便print控制台能看到Coze代码节点虽然也有日志面板但很多时候你不如直接“把中间结果返回出去”。也就是说想把某个中间值看清楚就把它的值塞进return的JSON里到下游节点去预览。这算是我自己摸索出来的土办法。比如抓回来的HTML特别长你可以在测试阶段临时返回resp.text的前500个字符看看页面结构到底长什么样再决定CSS选择器怎么写。别一上来就对着BeautifulSoup的选择器瞎猜用这种方法看几眼真实HTML比盲改十次都管用。3. 能跑的Python抓取方案代码逐行拆开讲3.1 完整代码长这样下面这段代码就是我在一次初实践里跑通的版本完整可运行你直接复制到Coze代码节点里配置好url入参就行import requests from bs4 import BeautifulSoup import re def main(url: str): headers { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0 Safari/537.36, Accept-Language: zh-CN,zh;q0.9 } try: resp requests.get(url, headersheaders, timeout10) resp.raise_for_status() resp.encoding resp.apparent_encoding soup BeautifulSoup(resp.text, html.parser) for tag in soup([script, style, noscript, iframe]): tag.decompose() title soup.title.get_text(stripTrue) if soup.title else content soup.get_text(separator\n, stripTrue) content re.sub(r\n{3,}, \n\n, content) return { code: 0, title: title, content: content[:5000], length: len(content) } except requests.exceptions.Timeout: return {code: 1, error: 请求超时请稍后重试或换一个链接} except Exception as e: return {code: 1, error: f抓取失败: {e}}这段代码不算短但每一块都有明确目的。下面拆开说。3.2 每一行为什么这么写先看headers。里面我写了一个常见的浏览器User-Agent。这个字段的目的是告诉目标服务器“我是一个普通浏览器”很多页面如果看到默认Python请求头会直接拒绝服务或者返回一个异常页面。不一定所有网站都需要但带上成本很低、收益很高属于基础礼貌。然后是requests.get(url, headersheaders, timeout10)。timeout10是我的固定习惯意思是10秒内连不上或者10秒内没收到响应就放弃。代码节点运行环境对单次执行时长有严格限制如果请求无限等下去节点会被整个掐断到时候你连错误信息都看不到。所以超时时间必须明确宁可失败重来也不要卡死。resp.raise_for_status()是用来检查HTTP状态码的。如果返回了404、403这类错误它会让程序跳转到异常处理分支把错误信息返回来。有了这一行你不会把“404页面”当成正常网页去解析出一堆乱码标题。resp.encoding resp.apparent_encoding是处理中文乱码的关键。很多网页没在响应头里写清楚字符集Python用默认编码去解码就乱码了。apparent_encoding会从内容里自动推断编码基本能解决90%以上的乱码问题。接下来是BeautifulSoup的部分。先拿到整个HTML解析成soup对象然后把script、style、noscript、iframe这些标签全部删掉。为什么要删因为网页正文里经常掺杂着大量脚本代码、样式定义和隐藏内容用get_text拿到所有文本时这些噪音会混进来。删干净之后正文才像个人样。再往下get_text(separator\n, stripTrue)的意思是把所有文本按换行符拼接起来并且把每一行首尾的空格去掉。separator\n保证了标题、段落、列表项之间会自然换行。之后用正则re.sub(r\n{3,}, \n\n, content)把连续三个及以上的换行压缩成两个不然你抓回来的正文里经常会出现一眼望不到底的空白行。最后返回的时候我统一做了content[:5000]截断。50个字符作为例子实际跑我会根据后续模型节点的上下文窗口来调整。这是后面会细说的一种策略先记住这个思路。3.3 返回结构这样设计下游才省心我特意把返回值设计成code、title、content、length、error这几个字段而不是成功了就返回内容、失败了就抛异常。原因是代码节点一旦抛异常工作流会显示“节点执行失败”但具体失败原因常常隐在日志深处。如果你把异常信息放进error字段、用code1表示失败下游的LLM节点就能拿到这个错误然后自然地告诉用户“抓取失败了请换一个链接”整个交互体验会顺畅很多。length字段也很有用。它可以直观告诉你看这篇抓回来的正文有多长方便判断是不是该分段处理。比如length只有几十个字那基本可以断定这个页面不是正文页可能是跳转页、验证页或者动态加载页面。这些判断写在工作流里比人肉盯着节点输出高效得多。4. 把抓到的正文喂给大模型工作流串联4.1 代码节点到LLM节点的变量衔接代码节点单独能跑还不够它得和生产环境里的LLM节点连起来才有意义。搭的步骤很简单开始节点定义参数url代码节点引入这个参数作为入参代码节点输出后再用一个LLM节点接收content字段最后LLM的结果通过结束节点返回给用户。关键动作在LLM节点的提示词里。你需要把代码节点返回的content字段插入到Prompt中。Coze的编辑界面里一般左侧能选“插入变量”你选择代码节点的输出、再选择content这个字段系统会自动生成类似{{fetch_result.content}}的引用。不要自己手写花括号手写出错概率很高直接从界面插入最稳。插入之后提示词可以这样写你是一位文章分析助手。下面是从网页中抓取到的文章内容请用150字以内总结这篇文章的核心观点再列出3个关键信息点。如果文章内容为空或只有错误信息请直接说“内容抓取失败”不要编造。 文章标题{{fetch_result.title}} 文章内容{{fetch_result.content}}注意最后那句“不要编造”。因为代码节点抓回来的内容不一定干干净净有时候正文不完整模型如果觉得自己能脑补就会顺着标题瞎编。加上这句约束等于给模型划了一条底线让它没料可写的时候就老实承认。4.2 单次截断 vs 分段多轮摘要文章一长问题就来了。代码节点返回的content如果直接全文投给LLM节点轻则token费用上涨重则超出上下文窗口直接报错。所以你得有取舍策略。最省事的方案是单次截断在代码里直接用content[:5000]只取前5000个字符交给模型。好处是流程稳定、快、便宜适合做“快速摘要”场景——对大多数文章而言前几千字符已经包含了核心开头和主线信息。缺点也很明显长文章的结论和数据往往在后半部分截断了就抓不到。如果非要处理超长文章就得做分段多轮摘要。思路是代码节点先把正文按段落切成若干块循环或者逐个投给LLM节点做局部摘要最后再让LLM节点把所有局部摘要汇总成总摘要。这个方案流程要复杂不少还需要用到循环节点或多次LLM调用。作为初实践我建议你先用单次截断跑通后面确实遇到长文需求再升级。不要第一步就追求完美架构很容易把自己劝退。4.3 一个可以直接抄的“链接内容摘要”工作流这里给你一个完整的参考搭建顺序我每次带新手也是按这个顺序来的开始节点设置一个输入字段名字叫url类型为String描述里写“请输入文章链接”。代码节点配置入参url粘贴上一节的Python代码先点“运行”用测试URL跑一次确认返回的title和content正确。LLM节点选择要用的模型在Prompt中插入代码节点输出的title和content引用按4.1的模板写提示词。结束节点把LLM节点的输出作为返回内容让用户直接看到结果。这套流程跑通之后你在智能体里丢一个链接它就能真实地给你输出文章摘要、核心观点、或者按你要求提取出来的信息点。整个过程里用户感知到的是“这个智能体会读文章了”而背后真正干脏活累活的其实就是那个代码节点。5. 实测最容易翻车的四个点与排查套路5.1 抓到的是空壳页面这是最让人崩溃的一类问题。代码明明执行成功返回的length却只有几百甚至几十title也奇奇怪怪。拿到这种结果先别急着改代码大概率是目标页面根本不在初始HTML里而是靠浏览器里的JavaScript动态渲染出来的。你用requests请求拿到的只是个外壳真正的正文藏在JS请求的接口或渲染后的DOM里。怎么快速判断在代码节点测试的时候临时返回一段resp.text[:500]看看。如果里面只有一堆script和空壳标签没有成段的文字那基本就是动态渲染页面。这种页面靠代码节点硬抓性价比极低。我一般的选择是换“打印版”或“阅读模式”的链接再试或者干脆换一个带浏览器渲染能力的节点来处理。不要在这类页面上死磕代码节点擅长的是静态页面让它干浏览器渲染的活纯属给自己添堵。5.2 请求被拒、超时与重试另一种常见情况是403或者卡在超时上。403多半是目标站点识别到了非浏览器请求主动拒绝了。先把User-Agent加好、把Accept-Language带上多数情况下能解决解决不了就放弃说明对方有更强的风控策略。超时的话先确认链接在浏览器里能不能正常打开有时候就是链接本身失效了和你的代码半毛钱关系都没有。这里必须多说一句频率问题。代码节点每次执行都会对目标站点发起一次请求。如果只是处理单条链接完全没问题但如果你把它搭在一个批量处理几十上百条链接的工作流里短时间高频请求很容易给目标网站造成负担也可能被对方拉黑。我的原则是抓取只服务于个人正当需求低频、少量、用完即走。能在本地先筛选好的链接绝不在工作流里循环抓。5.3 乱码和正文噪音乱码的问题绝大多数情况靠resp.encoding resp.apparent_encoding就能解决。个别老站点的编码比较固执可能还需要手动指定resp.encoding gbk这样的写死操作。怎么知道是哪种编码还是老办法打印resp.text开头几百字符看一眼乱码的样子基本能判断方向。正文噪音又是另一回事。你抓回来的文本可能夹杂着导航菜单、广告文案、评论区、版权声明。对摘要场景来说这些噪音会严重影响大模型的总结质量。打败噪音的思路有两层第一层是把明显无用的HTML标签删掉也就是代码里decompose那一行第二层是写一些简单的关键词过滤规则把“相关推荐”“热门阅读”“点击查看”这类常见导航短语去掉。第一层通用性强第二层属于针对目标站点的定制初实践阶段做不做都行。5.4 变量引用不出来怎么办工作流联调的时候最容易遇到的问题就是LLM节点里引用不到代码节点的输出。出现这种情况九个里面八个是字段名不对。去代码节点的输出预览里看它返回的JSON里到底有哪些键别凭记忆去填。比如你返回的是title引用的时候写成article_title就肯定引用不出来。看一眼输出预览比什么都直接。还有个容易混淆的点如果你在代码里把返回内容包了一层对象比如return {data: {...}}那下游引用就要多嵌套一层写成fetch_result.data.content。所以我建议返回结构尽量扁平不要随便套层级字段放得越平引用越省事。这算是我踩过几次坑之后总结出来的朴素经验。最后再分享一个我自己的小习惯每次新建代码节点永远先拿一个固定链接在节点测试面板里跑通确认返回字段符合预期再连LLM节点。我第一次搭的时候图省事没跑测试直接接下游结果LLM节点读到的永远是上一个测试链接的内容排查了好久才意识到是代码里写死了URL。先把节点输出打印出来看清楚再往上连整套流程的翻车率能降一大半。